Date post: | 20-Dec-2015 |
Category: |
Documents |
View: | 219 times |
Download: | 1 times |
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 3
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 4
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 5
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 6
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 7
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!
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 9
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.
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 11
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)
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 12
Graphical Model Editors – Why?
A picture says (sometimes) more… Waiting Paying
OutOfService
pay
deliver
serviced
pay
error
…than thousand words…
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 13
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?
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 14
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.”
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 15
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 16
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 17
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 18
Agenda
Modeling in Large-Scale Environments
Summary, References
Introduction to Model-Driven Development
The Model Integration Problem
Q&A
The Role of OCL
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 19
Non-Interoperable Islands, Proprietary Bridges
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 20
Goal: Smooth Interoperability, Homogeneous Bridges
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 21
Goal: Smooth Interoperability, Homogeneous Bridges
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 22
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, ...
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 23
Agenda
Modeling in Large-Scale Environments
Summary, References
Introduction to Model-Driven Development
The Model Integration Problem
Q&A
The Role of OCL
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 24
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 25
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>
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 26
Building Blocks – Central Services
Modeling Core
Model Transformation
& Code Generation
CentralServices
Query / Where-used
lists
Metamodel Linking
Reflection
Events
Undo / Redo
Persistence
Import / Export
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 27
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 28
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 29
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 30
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 31
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 32
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 33
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 34
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 35
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 36
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 37
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)
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 38
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 39
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 40
SC3
SC2SC1
Development Components: SC Usage
DC 1DC 3
DC 4
DC 5
SC Usage
DC Usage
DC 2
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 42
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 43
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 44
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 45
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 46
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 47
CBS Buildspaces
One CBS server can host multiple buildspaces
Separate isolated build environments
“Logical build servers” inside one CBS
Used for building different configurations
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 48
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 49
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
Mapping Model Partitions to Workspaces
After checking in Activity 1 its partitions have gone back to inactive state
Now check in Activity 2:
Activi-ty 2
chec
kin
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 50
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
Mapping Model Partitions to Workspaces
Nothing checked out anymore, no open activities
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 51
Mapping Model Partitions to Workspaces
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
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 2
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 52
Agenda
Modeling in Large-Scale Environments
Summary, References
Introduction to Model-Driven Development
The Model Integration Problem
Q&A
The Role of OCL
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 53
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 54
The OCL Standard 2/3
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 55
The OCL Standard 3/3
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.
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 56
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 57
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>>
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 58
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 59
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 60
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 61
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 62
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 63
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 67
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 68
“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>
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 69
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>
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 70
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)
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 71
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 72
Agenda
Modeling in Large-Scale Environments
Summary, References
Introduction to Model-Driven Development
The Model Integration Problem
Q&A
The Role of OCL
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 73
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.
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 74
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 75
MDA/MDD Resources (Books)
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 76
MDA/MDD Resources (Books)
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 77
MDA/MDD Resources (Books)
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
SAP AG 2006, Model-Driven Development at SAP / Axel Uhl / 78
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