Model-Driven Development at SAP July 12, 2006 Dr. Axel Uhl Chief Development Architect SAP Product Architecture

Model-Driven Development at SAPJuly 12, 2006

Dr. Axel Uhl

Chief Development Architect

SAP Product Architecture

SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 2

Agenda

Modeling in Large-Scale Environments

Summary, References

Introduction to Model-Driven Development

The Model Integration Problem

Q&A

The Role of OCL


The “Moore’s Law” of Platform Complexity

Platform complexity doubles every few years.Languages and Paradigms hardly keep up.

50’s 60’s 70’s 80’s 90’s 2000’s

Platforms Languages,Paradigms

hard-wired

assembly

3GLs, 4GLs

OO

Modeling


What’s “Modeling?”

Herbert Stachowiak, Allgemeine Modelltheorie: Isomorphic representation

A model represents some thing.Model and thing are connected by an isomorphism.

AbstractionThe model suppresses irrelevant detail and focuses on important aspects.

PragmaticsThe model is created for a purpose.

Examples of Models Crash test dummy

London subway map

UML model

C# source code


Modeling Applied to Software

“We model our software...” Models as guiding documents

don’t map directly to executable softwarecan help to communicateage fast if software evolves

Models that directly affect executable system (“Blueprinting”)executed directly by model interpretersubject to model transformation, mapping (closer) to an execution platformmay require refinement after mapping (“filling in the blanks”)may be combined with other models during mappingmay take multiple “hops” until reaching an execution platform


Textual vs. Graphical vs. Abstract

Metamodel defines Modeling Language

Textual Languages Modeling Languages

Abstract Syntax AST Metamodel

Concrete Syntax EBNF Notation specification

Why / When do we need Concrete Syntax?

To facilitate human users to easily comprehend, create and manipulate Models


Modeling: What Is It?

How can we manipulate Models?

Manipulation Type(syntax)

Examples

Programmatic(abstract)

JMI, EMF, proprietary APIs

Form-Based(abstract/concrete)

EMF.Edit, WebDynPro, SWT/Swing

Textual(concrete)

OCL, Action Semantics, AIM, Java, etc.

Graphical(concrete)

UML Diagrams, Petri nets, etc.

Which one is the best, depends on the Metamodel!


Form-Based Model Editors


Form-Based Model Editors

Generic Forms (using reflective API)

Metamodel-specific Forms

(+) Implement once, reuse for every Metamodel

(-) General usability issues, as for example grouping

(-) Directly Reflects the abstract syntax

(+) Can be customized to specific user needs

(-) A new one for each new Metamodel

(-) Requires programming knowledge

Challenges

• Declarative (platform independent)

• High customizable

• Usability Issues: D&D, non-Modal Dialogs, Live Update, etc.


Textual Model Editors


Synchronization?

Textual Model Editors

There are some Models that we do not want to edit graphically!

Abstract Syntax(Metamodel)

Concrete Syntax (e.g. EBFN)

Parser

Emitter

EditorModel Text

• Formatting• Syntax highlight• Intelli-sense• Debugging?

Challenges

• Specification of mapping between abstract and concrete syntaxes

• Automatic generation from concrete syntax specification (What can be generated?)

• Synchronization of Model and Text (Model / Text diff & merge)


Graphical Model Editors – Why?

A picture says (sometimes) more… Waiting Paying

OutOfService

pay

deliver

serviced

pay

error

…than thousand words…


Graphical Model Editors II

(+) Particularly appropriated to represent complex relationships

(-) Still difficult to program, even with GEF-style frameworks

(-) Graphical Meta Case tools have serious usability problems

Challenges

• How to specify a Graphical Notation for a given Metamodel

• To what extent can the Graphical Notation be specified by a Domain/Meta-modeler expert?

• Which parts of the editor can be automatically generated from the Graphical Notation specification?

• How to display and handle merge conflicts in graphical models?


Modeling Languages vs. Programming Languages

The Fundamental Difference: Executability programming languages used to express executable programs

modeling languages can also be used to model non-executable things

Representation Doesn’t Really Matter consider textual representation of a “modeling language”

consider graphical views of programs written in 3GLs

consider repository technologies used by smart IDEs (e.g., JDT)

The Superficial Perception “It’s graphical, therefore it’s modeling.”

“It’s stored as XML, thus it’s a model.”

“It’s a text-based language. This is programming.”


The Vision

Appropriate Modeling Languages I recognize the terms / concepts I know in the models I create and edit I don’t have to worry about things I don’t know Modeling Languages may be designed for direct runtime interpretation

Homogeneous Tools – Usage Patterns I don’t want to learn more than one way to do a certain task Examples: save, load, undo, query, validate, transform, check-out, check-in,

where-used lists

Longevity and Asset Protection I don’t want to re-do my work only because an architect had another fancy idea Nevertheless architectures can evolve with minimal loss of specifications

Re-Use and Interoperability I can browse, navigate, and link between different models

Quality The architect can enforce technology patterns and guidelines


porting effort withspecification provided

at abstract, portable levels

Platform 4(CRC)

Platform 3(UML)

Platform 2(J2EE)

Platform 1(Java)

amo

un

t o

f sp

ecif

icat

ion

co

nte

nt

completespecification

sketches

complete, deployedsystem

replace platforms 2&1

porting effort withspecification providedin platform-specificmodels

Model-Driven Development: Improved Portability

metamodels /modeling languages


Model-Driven Development: Improved Efficiency

Take Path of Least Effort Detailing at low abstraction level causes extra effort and errors.

Example: Associations between EJB components

Metamodels / Modeling Languages

amount of specification content


Agenda


Summary, References



Q&A

The Role of OCL


Non-Interoperable Islands, Proprietary Bridges


Goal: Smooth Interoperability, Homogeneous Bridges


Goal: Smooth Interoperability, Homogeneous Bridges


Main Tasks Before Us

Infrastructure Consolidate tool and repository infrastructures MOIN Use MOF as metadata standard; provide interop with Eclipse Modeling

Framework (EMF) where possible Allow for a (ideally small) number of workbench environments on top

EclipseVCVisual Studio .net

Content Align modeling languages and approaches

Basic ESA languages (BOs, UI, Process)Language(s) for composition (do they need to be separate?)Allow for more abstract and more detailed languages for the same domainContemplate use of action languages

Harmonize notations / representationsusability, standards, ...


Agenda


Summary, References



Q&A

The Role of OCL


Level MOF terms Examples Cardinality * User

M3 meta-meta-model

The “MOF” meta model 1 Standards developer

M2 metamodel, meta-meta-data

UML metamodel, CWM metamodel

10 … 100 Developer for tools or infrastructures

M1 model, metadata

UML models such as class diagrams for a specific application,CWM metadata

1,000 … 10,000 Application developer

M0 object, information

Instances of modeled class etc.,warehouse data

100,000 … 10,000,000

End user

Scaling It Up

* Cardinality should not be taken too literally here! The numbers are meant to give a rough feeling of the number of instances we expect "at SAP"

Number of developers / modelers on the same repository: 1..10000 SAP has customers with larger dev-orgs than itself

SAP has about 8000 developers


Modeling Core

Building Blocks – Models, Languages and Notations

Metamodels

Models

a model ina language

modeling languagedefinition

Graphical NotationDefinition

notation fora language

Diagrams

a diagram ina notationdiagram shows

elements of a model

myView : View

OK : Button

Cancel : Button

Please Choose : Label

Button Label

View

name : stringGraphicalElement0..*0..*

contents

Enter title here

Please choose

OK

Cancel

Enter title here

<buttontext>

<labeltext>


Building Blocks – Central Services

Modeling Core

Model Transformation

& Code Generation

CentralServices

Query / Where-used

lists

Metamodel Linking

Reflection

Events

Undo / Redo

Persistence

Import / Export


Building Blocks – Integration into Productive Environment

NWDI {

Modeling Core

CentralServices

Versioning LockingCentralBuild

Role Concept

Transport and Merge

ComponentModel

i18n Support

Tool Workbench Session Isolation

Scalable DB PersistenceModel Partitioning


MOF vs. EMF

EMF – The Eclipse Modeling Frameworksimplified version of MOF

no associationsresource assignment aligned with composition hierarchy

issueslarge composition hierarchies cannot be split across resources

scalability?lack of associations ties navigation and awareness together

adding association requires change of classes to which it attaches


MOF vs. EMF

MOF avoids scalability issues with EMF

doesn’t restrict compositions regarding model partitioninghas true associations (important for language federation)

current version 2.0some decent extensions over 1.4 (e.g., association subsetting, Element class)some questionable features (e.g., package merge, property redefinition)split of MOF standard into EMOF and CMOF adds much complexityno Java language binding as yet (only prototypes, e.g., at HU Berlin)no proven, scalable implementation exists

version 1.4proven, robust, several implementationsJava binding exists (JMI 1.0)missing features can be added in backward-compatible ways

Our Choice: MOF 1.4 + JMI 1.0 with minor compatible extensions


Development Process in ABAP

Check-out & Change development

objects

Logon to SAP development

system

Activate changes

Test application

ReleaseTransport

Defines the whole environment of own and foreign components

Implicit check of syntactic correct-ness, rejected if build fails.

After activation: visibility for every-onevery => early integration of foreign changes

=> early detection of errors


NW Development Infrastructure: Learning from ABAP

Test application

Copy & Checkout source files, change development objects

Logon to NWDI DevSpace

Build centrally &

Activate changes

Release forTransport ABAPJava

Defines the whole environment of own and foreign

components

Check-out & Change development

objects

Logon to SAP development

system

Activate changes

Test application

ReleaseTransport

Correct libraries are copied auto-matically

Implicit check forformal correctness

visibility for everyone

early integration

Developer testswithin the central

environment


NWDI Based Development: Process

Local DC BuildLocal J2EETest System

Local File System

CBSDTR Server

Software LogisticsCMS

Central J2EETest System

inact

act

2

4

3

5

Build

8

9 11b

11a

7

Build10

Test succeeds

Test succeeds

Lo

cal D

ev. E

nvi

ron

men

tC

entr

al D

ev. E

nvi

ron

men

t

6

12 Release

SAP NetWeaverDeveloper Studio UI

SLD Dev.Conf.

1

ActivateCheck in

Name Server

4b


Design-Time Repository (DTR) – Goals

Distributed, concurrent development

Distributed versioning that spans repositories

Conflict detection

Support for conflict resolution

Open

Based on open standards – WebDAV, DeltaV


DTR – Customer Scenario

Repository 1 (SAP) Repository 2 (Customer)

WSDEV WSCONS

a1

b1

b2

a1

b1

b2

WSCUST

c1a3

Install

apply SP1Alternative 1: Accept integrated version

a3

Back Integration

a2

Alternative 3: Merge both versions

consolidate

bug fixesongoingdevelopment

Conflict resolution

customermodification

consolidateAlternative 2: Accept existing versionc2


Component Model - Features

Encapsulation/Decoupling

Reusable elements explicitly declared public

Access control lists restrict component usage

Nested components

Controlling Dependencies Explicit declaration of dependencies

Checked by build process

Build Support

Predefined build templates for component types

Generic Model

Independent of technology / programming language

Tools

Fully integrated in SAP NetWeaver Developer Studio


Component Model Elements

Software Component

Development Component

Software Components (SCs)

Unit of delivery, installation and upgrade

Development Components (DCs)

Unit of build and deployment

Interfaces called “Public Parts”

Development Objects (DO)

Stored as versioned files in the source repository

Example: Java source filex.java y.xml…

Public Part


DC1

Development Components: Public Parts

Public Part

Groups elements that may be used by other DCs

In addition to package concepts of programming language (Java etc)

Public Part Purpose

C1 C2 C3 C4 C5

API.jar DC1.sda

build results

Public Part “API”

compile (build)used to compile the using DC

assemblyphysically packed into build result of using DC (e.g. EAR)


DC1

Public Parts: Implementation

C1 C2 C3 C4 C5API.jar

DC1.sda

Public Part “API”

gen

public

API

lib

dbg

java

deploy

DC2

use

compile

component build results in file system


Development Components: Usage Dependencies

Usage Dependencies

Declare that a DC uses parts of other DCs

Objects from other DCs can only be used if

The used object is element of a public part

A usage dependency exists

Component build detects violations of this rule

DC2

C3 C4 C5 C6 C7

DC3C8

DC1C1 C2

Usage dependency

Public Part


SC3

SC2SC1

Development Components: SC Usage

DC 1DC 3

DC 4

DC 5

SC Usage

DC Usage

DC 2


CBS – Features

Immediate build of changes on request by developers

Automatic rebuild of dependent DCs

Triggers deployment of new build results into central test server

Provides access to latest build results for developers

Web UI (administration)

Parallel execution of build requests


CBS – Activation Concept

Activating Changes

Additional step after check in

Each code line represented by two DTR workspaces (active, inactive)

Inactive Workspace

Changes are done only here

Active Workspace

Has only successfully built sources

Always in sync with archives available from CBS


CBS – Activation Check

Activation: Successful central build is required

Integration of changes into active workspace …

Deployment into central test server …

Change propagation to other locations …

→ Only for changes that were successfully built


CBS – Activation: Additional Isolation

Convention

Own DCs: developer works with inactive state

Used DCs: use active state

Sharing inactive state

Small teams may share inactive sources

Allows sharing changes before they work or even compile

Checking in code with errors does not affect other teams


CBS

CBS – Build Process (Activation)

Archive Pool

DC 3 Archives

Temporary Folder

DTR

Build

DC 2

DC 4 Archives

DC 1 Archives

DC 2 ArchivesDC2 Archives

DC 1

DC 3

DC 4

inactive workspace

DC 2

active workspace

DC 2

a b c d

a b c d

DC 2

a

b

c

d

activity 1


CBS Buildspaces

One CBS server can host multiple buildspaces

Separate isolated build environments

“Logical build servers” inside one CBS

Used for building different configurations


Mapping Model Partitions to Workspaces

Each model partition can be seen by client in either of three NWDI stateschecked-out

inactive

active

Assume we have two activities with 3/2 partitions

client XY

inactive

active

persisted partitions out of scope

not existing in persistency

partitions in scope

Partitions in changeable DCsPartitions in

imported DCs

„External“ SCVs

Checked-outpartitions

Current DevConfig

Partitions in DCs in client-spec

Activity 1Activi-

ty 2ch

ecki

n


client XY

inactive

active



partitions in scope


imported DCs

„External“ SCVs


Current DevConfig



After checking in Activity 1 its partitions have gone back to inactive state

Now check in Activity 2:

Activi-ty 2

chec

kin


client XY

inactive

active



partitions in scope


imported DCs

„External“ SCVs


Current DevConfig



Nothing checked out anymore, no open activities



Upon joint activation of Activity 1 and Activity 2 in CBS CBS views all partitions in their active state

except for the partitions from the activities to activate

client XY

inactive

active



partitions in scope


imported DCs

„External“ SCVs


Current DevConfig


Activity 1Activi-

ty 2


Agenda


Summary, References



Q&A

The Role of OCL


The OCL Standard 1/3

OCL stands for Object Constraint LanguageFormal specification (expression) language extension to UML (since 1.1)

Original focus: Express constraints (invariants) in UML models that cannot be captured in graphical notation

Can also be used to extend the MOF meta model (in analogy to UML)

OCL is rich enough for also expressing queries on model content, e.g., model transformation implementation event filtering

OCL 2.0 has a MOF-based metamodel for its abstract syntax

Level MOF terms OCL

M3 meta-meta-model OCL Specification

M2 meta-model, meta-meta-data OCL expressions embedded into Metamodel

M1 model, meta-data Evaluation of constraints on specific model (in a given extent)

M0 object, information N/A



Basic types of OCL expressions: Invariants

context Person inv: self.age < 18 implies self.fleet->forAll(v | not

v.oclIsKindOf(Car))

Defining new attributes or (query) operations

context Person define fleetSize() : Integer = self.fleet->size()

Pre/Post conditions for operations

context Person::sellVehicle()

pre: self.fleetSize() > 0post: self.fleetSize() = self.fleetSize@pre() - 1

Derivation rules

context Person::fullName derive:lastName.concat(‘, ’).concat(firstName)

Model

OCL



Basic types of OCL expressions Invariants

context Person inv: self.age < 18 implies

self.fleet->forAll(v | not v.oclIsKindOf(Car)) Defining new attributes or (query) operations

context Person define fleetSize():Integer = self.fleet->size()

Post conditions for operations

context Person::sellVehicle() post: self.fleetSize() = self.fleetSize@pre() - 1

Initialize attribute values

context Person::points init 0 Derivation rules

context Person::fullName derive: firstName.concat(‘ ’).concat(lastName)

Legend: █ Model █ OCL

An under-age person must not have a car.

Define a function that returns the number of vehicles that one person has.

Describe a constraint that states that after selling a vehicle, the number of vehicles is reduced by one.

Each person starts with zero points penalty register.

Define a derived attribute, which is the concatenation of first name and last name.


Query & OCL: Overview

Central query processorExposes query API and defines the

set of supported queries.

OCL queries can be mapped to those.

Delegates query task to repository core and persistence layer and integrates their response to one results

OCL Evaluator uses query processor

Impact analysis identifies a minimal subset of model elements and constraints that need to be checked after model changes

OCL Evaluator

OCL Parser

Impact Analysis

MOIN Core

Persistence Layer

Query API

NWDI Service

PhysicalPersistence

Query Processor

R

R

R

R

RR

R

R

R

R


MOF + OCL

OCL 2.0 Metamodel Attached to MOF 1.4 Metamodel New outermost package MOF

two clustered imports to Model and OCLnote this when doing a refOutermostPackage() with subsequent cast fully-qualified interface name: mof.MofPackage

OCL ModelCallExp adaptedOCL 2.0 normally based on UML 2.0 replaced references to UML 2.0 elements to corresponding OCL 2.0 elements

All references “non-intrusive” (Model package doesn’t know OCL)

PrimitiveTypes<<metamodel>>

Model<<metamodel>>

CorbaIdlTypes<<metamodel>>

OCL<<metamodel>>


OCL Constraints as Specialized MOF Constraints

EvaluationKind

immediatedeferred

<<enumeration>>ModelElement(from Model)

Constraint

expression : Stringlanguage : StringevaluationPolicy : EvaluationKind<<reference>> constrainedElements : ModelElement

(from Model)

1..*

0..n

+constrainedElement 1..*

+constraint 0..n

Constrains

OclExpression(from Expressions)

OclConstraint

<<reference>> oclExpression : OclExpression10..* +oclExpression 10..*

OclConstraintExpression


Allow for Explicit Semantics for OCL Constraints

OclConstraint

<<reference>> invariantOf : Classifier

Classifier(from Model)

0..*

0..*

+invariants 0..*

+invariantOf 0..*

ClassifierInvariant

OclConstraint

<<reference>> postconditionFor : Operation<<reference>> preconditionFor : Operation

Operation

isQuery : Boolean

(from Model)

0..*

0..*

+preconditions0..*

+preconditionFor

0..*

PreconditionConstraint

0..*

0..*

+postconditions0..*

+postconditionFor0..*

PostconditionConstraint


Specifying Operation Bodies

OclExpression

<<reference>> defines : Operation

(from Expressions)

Operation

isQuery : Boolean<<reference>> exceptions : Exception

(from Model)

0..1

0..n

+body0..1

+defines0..n

OperationBodyDefinition


Specifying Derivation of Attributes / Associations

Attribute

isDerived : Boolean

(from Model)

AssociationEnd

isNavigable : Booleanaggregation : AggregationKindmultiplicity : MultiplicityTypeisChangeable : Boolean

otherEnd()

(from Model)

OclExpression

<<reference>> associationEnd : AssociationEnd<<reference>> attribute : Attribute

(from Expressions)

0..1

0..1

+derivationExpression 0..1

+attribute 0..1

AttributeDerivationExpression

0..1

0..1

+derivationExpression

0..1

+associationEnd 0..1

AssociationEndDerivationExpression

Note: Only for read access


How to Scale Up OCL?

Evaluating a set of n OCL expressions over a model with m model elements requires effort O(n*m)

What to do after minor changes to a model? Naive approach: recompute all expressions (O(n*m))

Smart approach: analyze impact of change, recompute only affected pairs [expression / context] (roughly O(n))

Impact analysis is the only way to scale up OCL requires an event framework on the repository

will typically work heuristically

yields superset of set of [expression / context] that actually changed


What is OCL Impact Analysis about?

We have: A meta-model MM

A set of OCL expressions O attached to MM

A model M (an instance of MM)

Modification (events) E to M

We want: Minimal subset of O, O’ that

needs to be evaluated

For each element o of O’ the minimal set of elements in M that are context instances of o

ESI meta-model

I1: “All elements must have a unique name”I2: “Fixed Naming scheme”

A set of BOs

Changing the name of a BO

We want: I1, I2

I1: all BOs I2: just the BO that has been changed


Architecture


Component Interaction Example


Interesting Model Events

InsertET<c:Class> a new model element of type c has been created

DeleteET<c:Class> an existing model element of type c has been deleted

InsertRT<a:Association> a link has been added to association a

DeleteRT<a:Association> a link in association a has been deleted

updateAttribute<c:Class, a:Attribute> value for attribute a in model element of type c has been changed


“Class Scope Analysis”

Goal: Determine the set of relevant model changes (events) that affect an OCL expression

Assumption: OCL expression are relevant for all context instances (hence class scope analysis)

Algorithm: Traverse OCL AST depth-first

Tag each node with the set of events that are relevant for that node

Set for whole expression is the union of events for all its nodes

Tagging: AssociationEndCallExp insertRT<A>,deleteRT<A>

AttributeCallExp updateAttribute<C,Attr>

VariableExp „self“ insertET<C>

OperationCallExp „allInstances()“ {insert,delete}ET<C>


Class Scope Analysis Example

TypeExp„BO“

OperationCallExp„allInstances()“

IteratorExp„forAll()“

OperationCallExp„<>“

OperationCallExp„implies“

OperationCallExp„<>“

VariableExp„o1“

VariableExp„o2“

AttributeCallExp„name“

AttributeCallExp„name“

VariableExp„o1“

VariableExp„o2“

context BO inv UniqueNames:

BO.allInstances()->forAll(o1,o2 |

o1<> o2 implies o1.name <> o2.name)

iET<BO>dET<BO>

updAttr<name> updAttr<name>


Instance Scope Analysis

Goal: Reduce the number of context instances for which an OCL expression needs to be evaluated

Idea: For a model change event/model element pair, find for each relevant

OCL expression the “way back” to the context instances

IOW: For which context instances can we navigate to the element that has been affected?

Algorithm: Decompose expression into sub-expressions

For each node in a sub-expression determine for each event the reverse navigation paths to instances of the context class

“Trick”: Do not collect/compute instances, but specify proper OCL path

expressions (and let OCL evaluator optimize that)


75

?

self b.yAxB b.yA.z >=self.z

a5

a2

a3

a1

a460

65

50

70

75

60

65

50

70

70 7070 70

true

Why that hassle?

context A inv: self.xB->forAll(b | b.yA.z >= self.z)

A

z: intB

XxBxA

YyA yB1 ** *

updateAttribute(a1,z, 75) {a1}

Checking the modified instance is not enough!

75 75

updateAttribute(a5,z, 70) {a5} ?

75

true

false

75


Agenda


Summary, References



Q&A

The Role of OCL


Summary

Model-driven development (MDD) has many challenges and substantial benefits.

Heterogeneous environments can kill many of those benefits.

SAP prepares to use MDD at large scale, based on open standards.

Model transformations and OCL are essential MDD technologies.

Both pose huge challenges impact analysis, incremental transformations

refinements

We believe to have solutions for those challenges at SAP.


MDA/MDD Resources (Books)

Model Driven Architecture

Applying MDA to Enterprise Computing (OMG)

David S. Frankel

Executable UML

A Foundation for Model Driven ArchitectureMarc J. Balcer, Stephen J. Mellor



Generative Programming

Methods, Tools, and Applications

Krzysztof Czarnecki and Ulrich W. Eisenecker

Software Factories

Assembling Applications with patterns, Models, Frameworks, and Tools

Jack Greenfield and Keith Short with Steve Cook and Stuart Kent



MDA Explained

The Model Driven Architecture: Practice and PromiseAnneke Kleppe, Jos Warmer, Wim Bast

MDA Distilled

Principles of the Model-Driven Architecture

Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise



Convergent Architecture

Building Model-Driven J2EE Systems with UML

Richard Hubert

Allgemeine Modelltheorie; Herbert Stachowiak; Springer Verlag, 1973

Generative Programming - Methods, Tools, and Applications; Krzysztof Czarnecki and Ulrich W. Eisenecker; Addison-Wesley, 2000


OMG Resources, Specifications

MOF 1.4 specification: http://www.omg.org/docs/formal/02-04-03.pdf

UML profile for MOF: http://www.omg.org/docs/formal/04-02-06.pdf

XMI 1.2 Specification: http://www.omg.org/cgi-bin/docs/formal/02-01-01.pdf

OCL 2.0 specification: http://www.omg.org/docs/ptc/2005-06-06.pdf

MOF 2.0 QVT specification: http://www.omg.org/docs/ad/2005-07-01.pdf


Questions

?

Documents

Model-Driven Development at SAP July 12, 2006 Dr. Axel Uhl Chief Development Architect SAP Product Architecture