Axel uhl sap@md-day2011

Where Modeling Has Arrived
An Overview: Model-Driven Software Development at SAP

Dr. Axel Uhl, Chief Development Architect, Technology Strategy, SAP AG
November 24, 2011

Does Anyone Remember…?

MDA as thought of by the OMG
 MOF-centric
 Maybe using UML
 Common Warehouse Metamodel?
 Collection of implementation
technologies (Java, .net, CORBA,
Web Services)
 XML-based model interchange
 Typical set of services and concerns
(security, transactions)
 Intended for business domains
 Facilitated by model transformations

© 2011 SAP AG. All rights reserved. 2

Some of It Confused Many of Us

What’s optional? What’s mandatory?
 Do domain-specific languages (DSL) fit in, or is it only UML?

What works, what doesn’t?
 Can I really exchange my models (repeatedly) using XMI? Diagrams…?

What’s with CIM, PIM and PSM?

How much vendor support is there?
 What’s my choice of enterprise-grade MOF repository implementations?
 What if I already have other, non-MOF repositories?
 Does XMI really help me to get from one vendor’s tool to the next?
 If I design my MDA-compliant model transformations, will they survive?


What’s Modeling Anyway (or: Is Modeling ≡ UML)?

There are many commonalities in what we call “programming language” and
“modeling language.” Both
 have abstract and concrete syntax
 can be of rather declarative or imperative nature
 can use different types of representation
o (though we usually think of programming language artifacts as ASCII strings)
 strive for adequate abstractions, concern separation and aspect localization

Many challenges of “programming” also exist for “modeling”
 physical partitioning and management of artifacts, multi-level editing
 dependencies, extensibility
 teamwork aspects (change management, versioning, ...)

What’s the difference between
 a code generator / model transformer and a compiler?
 a piece of C++ code and a sequence chart?


Language History


Abstraction Improves Portability

complete replace platform components 2&1 complete, deployed
specification migration effort with system
specification provided
at abstract, portable levels
amount of specification content

migration effort with
specification provided
in platform-specific
ways

Enabling / cost reduction for
 architecture evolution
 optimization across layers

sketches stack of abstractions and languages
(examples only)
process models component behavior runtime
(e.g., ARIS) models (UML) (e.g., ABAP) (e.g., C/C++)


Abstraction Improves Development Efficiency

Take path of least effort
 Detailing at low abstraction level causes extra effort and errors.
 Example: write an object-oriented business application in assembler


Abstract Properly!

This is what the art of software design is all about.
 Focus on the application domain
 Suppress unnecessary detail
 Avoid unnecessary dependencies
 Anticipate future change
Sounds familiar?
Those are (more or less) key characteristics of modeling
 Represent some real thing homomorphically Prof. Dr. Herbert Stachowiak

 Representation and real thing are linked by a projection
 The projection is driven by the pragmatics


London Tube Map


Crash Test Dummy


Mannequins


Partial Views


Scale Models


...and the Wiring Plan as another Partial View


Modeling

How is a model trying to help?
 More adequate domain abstractions
 Less dependency on volatile underlying
platform(s)
 No unnecessary details
The modeling language and its environment
introduce a “platform” of their own (PIM vs. PSM…)
 This platform has its own fate and mission.
 It may decay just the same way as other
platforms have disappeared.
 Where’s your compiler that you wrote for your
DSL back in 2001…?


Models as Documentation

Example: SAP’s Technical
Architecture Modeling (TAM)
Standard
 UML enhancements for
architecture models

Required by SAP processes.

Accepted by architects.


Models for Interoperability and Standardization

Example: Banking Industry Architecture Network (BIAN)
 Standardizes a Service-Oriented Architecture (SOA) in the banking industry
 Defines a BIAN meta model using MOF
 Defines a UML profile allowing UML tools to edit BIAN models
 Uses Object Constraint Language (OCL) to validate domain models
o Against UML profile
o Against domain rules
 Generates HTML documentation from the models
 Will be able to generate XML Schemas from message types defined in models

http://www.bian.org/content


Structured Metadata / Models in Development at SAP

With SAP’s history, using repositories for structured metadata is very usual.

 ABAP and R/3 largely work this way.

 Many SAP tools followed this general paradigm.

 Only two out of hundreds use a MOF-compliant repository

 UML plays no role in “blueprint modeling” (models that impact the executable
software by transformation or interpretation)


The Tool Ticker – Integration Builder: Data Types

Data Type Name & Namespace

Software Components

Versions

Data Type Structure /
XML Schema


The Tool Ticker – Integration Builder: Business Objects

New Service Interface

New Data Type

New Business Object



Business Object
aggregates BO Nodes
Key

Data Structure
(Re-)Use of Data Types



Actions for
Business Logic Queries for retrieval of
BO Nodes

Associations between
BO Nodes


The Tool Ticker – ABAP BO Proxy Generator

ES Repository Browser Name Mapping

Type Mapping

Corresponding ABAP Data Type to
in ES Builder modeled Data Type


The Tool Ticker – ABAP BO Viewer

Key Data Structure

Business Object (Re-)Use of Data Types
aggregates BO Nodes

Name Mapping


The Tool Ticker – Maestro State & Action Modeling


The Tool Ticker – Visual Composer 05 (WD Pattern)

ES Browser connects
to ES Repository

Empty OIP Pattern


The Tool Ticker – Visual Composer 05 (WD Pattern)

BO Query

Search View

Result
View
Data Source
Query


The Tool Ticker – Visual Composer: UI Layout



A lot of input fields, but
only few are really needed


The Tool Ticker – Visual Composer: Pattern Configuration

Disable most of the
optional input fields

Search View


The Tool Ticker – Visual Composer: Analytical
Dashboards


The Tool Ticker – Portal Content Studio


The Tool Ticker – WD Java: Data Modeler


The Tool Ticker – WD Java: Navigation Modeler


The Tool Ticker – J2EE Toolset


The Tool Ticker – Java Dictionary


The Tool Ticker – Composite Application Framework


The Tool Ticker – Guided Procedures


The Tool Ticker – BEx Web Analyzer

Drag and
Drop


The Tool Ticker – ESA Tool Overview

Interface Structure Model
Interface Structure Model (Business Document Object) XML - Schema
Level 1 2 3 4 5 1 2 3 4 5
<X1>
<A1>
<A2>
<A2>
<A3>
<A3>
A1 A2
<A1>
<X2>
A3 <X3>
<C2>
X1 X2 X3 C2 <C1>
C1
<C1>

X X4 B3 B4 <X3>
<C2>

<X2>
<X4>
<B3>
<B4>
<B4>
<B3>
<X4>
Directed relationships <X1>

ESA Scenario
Solution Map Configured Scenario Sales Order
Quotation
Processing
RFQ Processing
at Customer

Variant Details Supply Planning
Sales Order
Purchase Order
Processing at
Process Interaction Model
Processing

(XI Repository)
Customer

A

Inbound Delivery
Outbound Delivery
Processing at
Processing
Customer

A

Supplier Invoice
Customer Invoice
Processing at
Processing
Customer

A

A Due Item Processing
Object Data Type
A Payment Processing
Payment Processing
Model
at Business Partner

Accounting
Payment processing Bank statement
A Document
at house bank creation at bank
Processing

Process Step Documentation

Status Model


The Tool Ticker – Solution Composer


The Tool Ticker – ARIS: Process Components


The Tool Ticker – Business Workflow


The Tool Ticker – Enterprise Data Warehouse: Transform.


The Tool Ticker – Enterprise Data Warehouse: Extraction


The Tool Ticker – ABAP Class Builder


The Tool Ticker – ABAP Web Dynpro


The Tool Ticker – ABAP: Graphical Screenpainter


The Tool Ticker – ABAP Data Modeler


The Tool Ticker – ABAP Dictionary: Foreign Keys


The Tool Ticker – Integration Builder: Business Scenarios


The Tool Ticker – BI: Query Designer


The Tool Ticker – BI: Report Designer


The Tool Ticker – BI: Web Application Designer


The Tool Ticker – Mobile Design Time


The Tool Ticker – JLin


The Tool Ticker – Unit Testing


The Tool Ticker – eCatt


The Tool Ticker – TestZone


The Tool Ticker – Web Dynpro Authoring Tool ABAP


The Tool Ticker – Web Dynpro Authoring Tool Java


The Tool Ticker

This could go on for a long time…
...
MOM, SLD, FDT, KM, Shanghai Tool, Easy Enhancement Workbench, ...
Few of these tools

- integrate in the same workbench environment

- use compatible, integrated model repository technology

- support end-to-end consistency checks

- support methods for agile refactoring


Or as Foote & Yoder Call It
Big Balls of Mud (Also Works for Spaghetti…)

“A BIG BALL OF MUD is haphazardly structured,
sprawling, sloppy, duct-tape and bailing wire,
spaghetti code jungle. We’ve all seen them. These
systems show unmistakable signs of unregulated
growth, and repeated, expedient repair. Information
is shared promiscuously among distant elements of
the system, often to the point where nearly all the
important information becomes global or
duplicated. The overall structure of the system may
never have been well defined. If it was, it may have
eroded beyond recognition. Programmers with a
shred of architectural sensibility shun these
quagmires. Only those who are unconcerned about
architecture, and, perhaps, are comfortable with the
inertia of the day-to-day chore of patching the holes
in these failing dikes, are content to work on such
systems.” [http://www.laputan.org/mud/]


Textual Modeling – An Important Trend?

Martin Fowler wrote about it
 http://www.martinfowler.com/articles/languageWorkbench.html

Several frameworks support it
 e.g., EMFText, Xtext, FURCAS, TMF, TCS, MontiCore, (Oslo)

General concept
 Consider the abstract syntax tree (AST) a model
 Consider the textual representation a view of a part of the model

Frameworks vary greatly…
 …in how they can deal with partial and/or overlapping views
 …in how they preserve lexical information (whitespaces, line breaks, comments)
 …in how they can store, retrieve and manage the models
 …in what textual grammar classes they support
 …in how powerful the mapping between meta model and textual syntax can be.


Different Approaches towards Textual DSLs
Compilers, hand-written

File System
Parse into repository for
Compiler-Compilers, lex/yacc et al.
improved tool support; hand-written
.o smart editors with
Compiler .class
syntax and error highlighting;
File System see SNiFF, Eclipse JDT and others

Language workbench,
.o
Compiler .class deriving editor, parser
and index automatically
“Index”
from mapping
specification

resulting in different
Graphical
Textual qualities
Tools
Tools
geared towards different
boundary conditions
both make language
design with tool support a
lot easier
Textual tools, projectional editors, working
Graphical tools, working on structured object repository, database-like
on structured object repository,
database-like

A Real Difference: Partial, Overlapping

Wheel is part of two diagrams; each diagram only shows part of the domain

vehicles vehicles

Vehicle +wheels Wheel
0..1 1..*

+doors Wheel
Car Door
0..1 0..*
0..1

1 +engine
Engine

The challenge: updates through one view may update another



Add attributes to Wheel

vehicles vehicles

0..1 1..*

Car +doors Door
0..1 0..*
0..1

1 +engine
Engine



They also show up here, distort the layout and go against the view’s purpose

vehicles vehicles



So we remove them from the other view, but not the underlying domain model

vehicles vehicles

0..1 1..*

Car +doors Door
0..1 0..*
0..1

1 +engine
Engine



Adding classes and associations, however, typically does not alter other views

vehicles vehicles

0..1 1..*

Car +doors Door
0..1 0..*
0..1

1 +engine
Engine



With partial, overlapping views, delete has to come in two flavors. Delete from view…

vehicles vehicles

0..1 1..*

Car +doors Door
0..1 0..*
0..1

1 +engine
Engine



…and delete from domain model

vehicles vehicles

0..1 1..*

Car +doors Door
AirPressureSensor
0..1 0..*
0..1

1 +engine
Engine


Imagine the same for Text

Wheel class showing in two views of the vehicles package, one of them partial

package vehicles {
class Vehicle { package vehicles {
Wheel 1..* wheels; class Wheel {
} }
class Wheel {} }
class Car extends Vehicle {
Door 0..* doors;
Engine 1..1 engine;
}
class Engine {}
}



Wheel class as partial view; Package vehicles with two partial views

package vehicles {
} Double radius;
class Wheel {} Boolean tubeless;
class Car extends Vehicle { Double width;
Door 0..* doors; AirPressureSensor 0..1 airPressureSensor;
Engine 1..1 engine; }
} class AirPressureSensor {}
class Engine {} }
}



Add attributes to Wheel class

package vehicles {
} Double radius;
Door 0..* doors; }
}
class Engine {}
}



Attributes also show up here

package vehicles {
class Vehicle {
Wheel 1..* wheels;
package vehicles {
}
class Wheel {
class Wheel {
Double radius;
Double radius;
Boolean tubeless;
Boolean tubeless;
Double width;
Double width;
}
}
}
class Car extends Vehicle {
Door 0..* doors;
Engine 1..1 engine;
}
class Engine {}
}



So we remove them from the other view, but not the underlying domain model

package vehicles {
} Double radius;
Door 0..* doors; }
}
class Engine {}
}



Adding classes and associations may not alter other views

package vehicles {
} Double radius;
class Engine {} }
}



With partial, overlapping views, delete has to come in two flavors. Delete from view…

package vehicles {
} Double radius;
class Engine {} }
}



…and delete from domain model

package vehicles {
} Double radius;
class Engine {} }
}

This is pretty unusual for a text editor.
But it is what happens when you apply the core principles of modeling.
Under which circumstances is this useful?


Is Modeling a Lost Cause?

Not necessarily
 Some convergence on Eclipse / EMF (at least somehow like EMOF)
 Starting to use EMF as façade for existing design-time data / models
 UML in widespread use for documentation
 OCL starting to gain foothold in model validation
 Some “textual modeling” starting, mostly based on EMF

However
 Still too many heterogeneous repositories and tool workbenches
 Model interchange (XMI?) does not seem to solve our problems
 No standards in use for model transformation / code generation
 Tools lag behind in quality compared to tools for handling source code


Summary

Modeling adds to the history of computing
 Partial and overlapping views, using different forms of notation
 Comes with its own set of challenges

Until modeling tools reach the maturity of, say, an Eclipse JDT, developers will
perceive them as hindrance rather than accelerator.

We need broadly-accepted and working standards

We shouldn’t try to automate insoluble mapping problems.
 “Computer! Turn my little high-level sketch into an executable system!”

“Textual modeling” trend can bridge some gaps in interesting ways.


Thank You!

Questions?

axel.uhl@sap.com


© 2011 SAP AG. Alle Rechte vorbehalten.

Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, Java ist eine eingetragene Marke von Sun Microsystems, Inc.
zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche JavaScript ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet
schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation unter der Lizenz der von Netscape entwickelten und implementierten Technologie.
enthaltene Informationen können ohne vorherige Ankündigung geändert werden.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects
Die von SAP AG oder deren Vertriebsfirmen angebotenen Softwareprodukte Explorer, StreamWork und weitere im Text erwähnte SAP-Produkte und -
können Softwarekomponenten auch anderer Softwarehersteller enthalten. Dienstleistungen sowie die entsprechenden Logos sind Marken oder eingetragene
Microsoft, Windows, Excel, Outlook, und PowerPoint sind eingetragene Marken Marken der SAP AG in Deutschland und anderen Ländern.
der Microsoft Corporation. Business Objects und das Business-Objects-Logo, BusinessObjects, Crystal
IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, Reports, Crystal Decisions, Web Intelligence, Xcelsius und andere im Text
System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, erwähnte Business-Objects-Produkte und Dienstleistungen sowie die
zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 entsprechenden Logos sind Marken oder eingetragene Marken der Business
Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, Objects Software Ltd. Business Objects ist ein Unternehmen der SAP AG.
POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, Sybase und Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere und
BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, weitere im Text erwähnte Sybase-Produkte und -Dienstleistungen sowie die
Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, entsprechenden Logos sind Marken oder eingetragene Marken der Sybase Inc.
Netfinity, Tivoli und Informix sind Marken oder eingetragene Marken der IBM Sybase ist ein Unternehmen der SAP AG.
Corporation.
Alle anderen Namen von Produkten und Dienstleistungen sind Marken der
Linux ist eine eingetragene Marke von Linus Torvalds in den USA und anderen jeweiligen Firmen. Die Angaben im Text sind unverbindlich und dienen lediglich zu
Ländern. Informationszwecken. Produkte können länderspezifische Unterschiede
Adobe, das Adobe-Logo, Acrobat, PostScript und Reader sind Marken oder aufweisen.
eingetragene Marken von Adobe Systems Incorporated in den USA und/oder Die in dieser Publikation enthaltene Information ist Eigentum der SAP. Weitergabe
anderen Ländern. und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem
Oracle ist eine eingetragene Marke der Oracle Corporation. Zweck und in welcher Form auch immer, nur mit ausdrücklicher schriftlicher
UNIX, X/Open, OSF/1 und Motif sind eingetragene Marken der Open Group. Genehmigung durch SAP AG gestattet.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame und
MultiWin sind Marken oder eingetragene Marken von Citrix Systems, Inc.
HTML, XML, XHTML und W3C sind Marken oder eingetragene Marken des
W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.


Axel uhl sap@md-day2011

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to Axel uhl sap@md-day2011

Similar to Axel uhl sap@md-day2011 (20)

More from MDDAY11

More from MDDAY11 (6)

Recently uploaded

Recently uploaded (20)

Axel uhl sap@md-day2011