Top Banner
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
97
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: 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

Page 2: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 2

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

Page 3: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 3

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?

Page 4: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 4

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?

Page 5: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 5

Language History

Page 6: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 6

Language History

Page 7: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 7

Language History

Page 8: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 8

Abstraction Improves Portability

migration effort with

specification provided

at abstract, portable levels

process models

(e.g., ARIS)

component

models (UML)

behavior

(e.g., ABAP)

runtime

(e.g., C/C++)

am

ou

nt

of

sp

ec

ific

ati

on

co

nte

nt

complete

specification

sketches

complete, deployed

system

replace platform components 2&1

migration effort with

specification provided

in platform-specific

ways

stack of abstractions and languages

(examples only)

Enabling / cost reduction for

architecture evolution

optimization across layers

Page 9: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 9

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

Page 10: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 10

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

Representation and real thing are linked by a projection

The projection is driven by the pragmatics

Prof. Dr. Herbert Stachowiak

Page 11: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 11

London Tube Map

Page 12: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 12

Crash Test Dummy

Page 13: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 13

Mannequins

Page 14: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 14

Partial Views

Page 15: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 15

Scale Models

Page 16: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 16

...and the Wiring Plan as another Partial View

Page 17: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 17

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

Page 18: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 18

Models as Documentation

Example: SAP’s Technical

Architecture Modeling (TAM)

Standard

UML enhancements for

architecture models

Required by SAP processes.

Accepted by architects.

Page 19: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 19

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

Page 20: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 20

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)

Page 21: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 21

The Tool Ticker – Integration Builder: Data Types

Software Components

Versions

Data Type Name & Namespace

Data Type Structure /

XML Schema

Page 22: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 22

The Tool Ticker – Integration Builder: Business Objects

New Business Object

New Data Type

New Service Interface

Page 23: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 23

Key

Business Object

aggregates BO Nodes

(Re-)Use of Data Types

Data Structure

The Tool Ticker – Integration Builder: Business Objects

Page 24: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 24

The Tool Ticker – Integration Builder: Business Objects

Associations between

BO Nodes

Queries for retrieval of

BO Nodes

Actions for

Business Logic

Page 25: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 25

The Tool Ticker – ABAP BO Proxy Generator

ES Repository Browser

Corresponding ABAP Data Type to

in ES Builder modeled Data Type

Name Mapping

Type Mapping

Page 26: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 26

The Tool Ticker – ABAP BO Viewer

Key

Business Object

aggregates BO Nodes (Re-)Use of Data Types

Data Structure

Name Mapping

Page 27: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 27

The Tool Ticker – Maestro State & Action Modeling

Page 28: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 28

The Tool Ticker – Visual Composer 05 (WD Pattern)

ES Browser connects

to ES Repository

Empty OIP Pattern

Page 29: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 29

The Tool Ticker – Visual Composer 05 (WD Pattern)

BO Query

Query

Search View

Result

View Data Source

Page 30: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 30

The Tool Ticker – Visual Composer: UI Layout

Page 31: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 31

The Tool Ticker – Visual Composer: UI Layout

Page 32: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 32

The Tool Ticker – Visual Composer: UI Layout

A lot of input fields, but

only few are really needed

Page 33: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 33

The Tool Ticker – Visual Composer: Pattern Configuration

Disable most of the

optional input fields

Search View

Page 34: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 34

The Tool Ticker – Visual Composer: Analytical

Dashboards

Page 35: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 35

The Tool Ticker – Portal Content Studio

Page 36: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 36

The Tool Ticker – Portal Content Studio

Page 37: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 37

The Tool Ticker – WD Java: Data Modeler

Page 38: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 38

The Tool Ticker – WD Java: Navigation Modeler

Page 39: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 39

The Tool Ticker – J2EE Toolset

Page 40: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 40

The Tool Ticker – J2EE Toolset

Page 41: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 41

The Tool Ticker – Java Dictionary

Page 42: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 42

The Tool Ticker – Composite Application Framework

Page 43: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 43

The Tool Ticker – Guided Procedures

Page 44: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 44

The Tool Ticker – Guided Procedures

Page 45: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 45

The Tool Ticker – Guided Procedures

Page 46: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 46

The Tool Ticker – Guided Procedures

Page 47: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 47

The Tool Ticker – BEx Web Analyzer

Drag and

Drop

Page 48: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 48

The Tool Ticker – ESA Tool Overview

AccountingDocumentProcessing

A

Sales OrderProcessing

Sales OrderQuotation

Processing

Inbound DeliveryProcessing at

Customer

Supplier InvoiceProcessing at

Customer

Payment processingat house bank

RFQ Processingat Customer

Purchase OrderProcessing at

Customer

Customer InvoiceProcessing

Due Item Processing

Payment Processing

A

A

A

A

A

Bank statementcreation at bank

Outbound DeliveryProcessing

Supply Planning

Payment Processingat Business Partner

Process Interaction Model

(XI Repository)

Configured Scenario

Variant Details

Solution Map

ESA Scenario

Process Step Documentation

Status Model

Object Data Type

Model

Interface Structure Model

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X

Directed relationships

Level 1 2 3 4 5

<X1>

<A1>

<A2>

<\A2>

<A3>

<\A3>

<\A1>

<X2>

<X3>

<C2>

<C1>

<\C1>

<\C2>

<\X3>

<\X2>

<X4>

<B3>

<B4>

<\B4>

<\B3>

<\X4>

<\X1>

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X

Directed relationships

Level 1 2 3 4 5 1 2 3 4 5

XML - SchemaInterface Structure Model (Business Document Object)

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X

Directed relationships

Level 1 2 3 4 5

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X

Directed relationships

Level 1 2 3 4 5

<X1>

<A1>

<A2>

<\A2>

<A3>

<\A3>

<\A1>

<X2>

<X3>

<C2>

<C1>

<\C1>

<\C2>

<\X3>

<\X2>

<X4>

<B3>

<B4>

<\B4>

<\B3>

<\X4>

<\X1>

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X

Directed relationships

Level 1 2 3 4 5

C1C2

B3

A1 A2

A3

B4

X1 X2 X3

X4X

Directed relationships

Level 1 2 3 4 5 1 2 3 4 5

XML - SchemaInterface Structure Model (Business Document Object)

Page 49: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 49

The Tool Ticker – Solution Composer

Page 50: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 50

The Tool Ticker – ARIS: Process Components

Page 51: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 51

The Tool Ticker – Business Workflow

Page 52: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 52

The Tool Ticker – Business Workflow

Page 53: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 53

The Tool Ticker – Business Workflow

Page 54: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 54

The Tool Ticker – Business Workflow

Page 55: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 55

The Tool Ticker – Business Workflow

Page 56: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 56

The Tool Ticker – Enterprise Data Warehouse: Transform.

Page 57: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 57

The Tool Ticker – Enterprise Data Warehouse: Extraction

Page 58: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 58

The Tool Ticker – ABAP Class Builder

Page 59: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 59

The Tool Ticker – ABAP Web Dynpro

Page 60: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 60

The Tool Ticker – ABAP: Graphical Screenpainter

Page 61: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 61

The Tool Ticker – ABAP Data Modeler

Page 62: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 62

The Tool Ticker – ABAP Dictionary: Foreign Keys

Page 63: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 63

The Tool Ticker – Integration Builder: Business Scenarios

Page 64: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 64

The Tool Ticker – BI: Query Designer

Page 65: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 65

The Tool Ticker – BI: Report Designer

Page 66: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 66

The Tool Ticker – BI: Web Application Designer

Page 67: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 67

The Tool Ticker – Mobile Design Time

Page 68: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 68

The Tool Ticker – Mobile Design Time

Page 69: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 69

The Tool Ticker – JLin

Page 70: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 70

The Tool Ticker – Unit Testing

Page 71: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 71

The Tool Ticker – eCatt

Page 72: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 72

The Tool Ticker – TestZone

Page 73: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 73

The Tool Ticker – Web Dynpro Authoring Tool ABAP

Page 74: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 74

The Tool Ticker – Web Dynpro Authoring Tool Java

Page 75: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 75

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

Page 76: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 76

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

Page 77: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 77

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.

Page 78: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 78

Different Approaches towards Textual DSLs Compilers, hand-written

Compiler-Compilers, lex/yacc et al.

Language workbench,

deriving editor, parser

and index automatically

from mapping

specification

Graphical

Tools

Graphical tools, working

on structured object repository,

database-like

Textual

Tools

Textual tools, projectional editors, working

on structured object repository, database-like

Parse into repository for

improved tool support; hand-written

smart editors with

syntax and error highlighting;

see SNiFF, Eclipse JDT and others File System

Compiler .o

.class

“Index”

File System

Compiler .o

.class

resulting in different

qualities

geared towards different

boundary conditions

both make language

design with tool support a

lot easier

Page 79: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 79

A Real Difference: Partial, Overlapping

Vehicle Wheel

1..*0..1

+wheels

1..*0..1

DoorCar

0..*0..1

+doors

0..*0..1

Engine

1

0..1

+engine1

0..1

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

Wheel

vehicles vehicles

The challenge: updates through one view may update another

Page 80: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 80

A Real Difference: Partial, Overlapping

Vehicle Wheel

1..*0..1

+wheels

1..*0..1

DoorCar

0..*0..1

+doors

0..*0..1

Engine

1

0..1

+engine1

0..1

Add attributes to Wheel

vehicles vehicles

Page 81: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 81

A Real Difference: Partial, Overlapping

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

vehicles vehicles

Page 82: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 82

A Real Difference: Partial, Overlapping

Vehicle Wheel

1..*0..1

+wheels

1..*0..1

DoorCar

0..*0..1

+doors

0..*0..1

Engine

1

0..1

+engine1

0..1

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

vehicles vehicles

Page 83: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 83

A Real Difference: Partial, Overlapping

Vehicle Wheel

1..*0..1

+wheels

1..*0..1

DoorCar

0..*0..1

+doors

0..*0..1

Engine

1

0..1

+engine1

0..1

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

vehicles vehicles

Page 84: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 84

Vehicle

Car

Engine

1

0..1

1

0..1

0..*0..10..1

+doors

0..*

Door

+engine

Vehicle Wheel

1..*0..1

+wheels

1..*0..1

DoorCar

0..*0..1

+doors

0..*0..1

Engine

1

0..1

+engine1

0..1

A Real Difference: Partial, Overlapping

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

vehicles vehicles

Page 85: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 85

Vehicle

Car

Engine

1

0..1

1

0..1

0..*0..10..1

+doors

0..*

Door

+engine

Vehicle Wheel

1..*0..1

+wheels

1..*0..1

DoorCar

0..*0..1

+doors

0..*0..1

Engine

1

0..1

+engine1

0..1

A Real Difference: Partial, Overlapping

…and delete from domain model

AirPressureSensor

vehicles vehicles

Page 86: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 86

Imagine the same for Text

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

package vehicles {

class Vehicle {

Wheel 1..* wheels;

}

class Wheel {}

class Car extends Vehicle {

Door 0..* doors;

Engine 1..1 engine;

}

class Engine {}

}

package vehicles {

class Wheel {

}

}

Page 87: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 87

Imagine the same for Text

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

package vehicles {

class Vehicle {

Wheel 1..* wheels;

}

class Wheel {}

class Car extends Vehicle {

Door 0..* doors;

Engine 1..1 engine;

}

class Engine {}

}

package vehicles {

class Wheel {

Double radius;

Boolean tubeless;

Double width;

AirPressureSensor 0..1 airPressureSensor;

}

class AirPressureSensor {}

}

Page 88: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 88

Imagine the same for Text

Add attributes to Wheel class

package vehicles {

class Vehicle {

Wheel 1..* wheels;

}

class Wheel {}

class Car extends Vehicle {

Door 0..* doors;

Engine 1..1 engine;

}

class Engine {}

}

package vehicles {

class Wheel {

Double radius;

Boolean tubeless;

Double width;

}

}

Page 89: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 89

Imagine the same for Text

Attributes also show up here

package vehicles {

class Vehicle {

Wheel 1..* wheels;

}

class Wheel {

Double radius;

Boolean tubeless;

Double width;

}

class Car extends Vehicle {

Door 0..* doors;

Engine 1..1 engine;

}

class Engine {}

}

package vehicles {

class Wheel {

Double radius;

Boolean tubeless;

Double width;

}

}

Page 90: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 90

Imagine the same for Text

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

package vehicles {

class Vehicle {

Wheel 1..* wheels;

}

class Wheel {}

class Car extends Vehicle {

Door 0..* doors;

Engine 1..1 engine;

}

class Engine {}

}

package vehicles {

class Wheel {

Double radius;

Boolean tubeless;

Double width;

}

}

Page 91: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 91

Imagine the same for Text

package vehicles {

class Vehicle {

Wheel 1..* wheels;

}

class Wheel {}

class Car extends Vehicle {

Door 0..* doors;

Engine 1..1 engine;

}

class Engine {}

}

package vehicles {

class Wheel {

Double radius;

Boolean tubeless;

Double width;

AirPressureSensor 0..1 airPressureSensor;

}

class AirPressureSensor {}

}

Adding classes and associations may not alter other views

Page 92: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 92

Imagine the same for Text

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

package vehicles {

class Wheel {

Double radius;

Boolean tubeless;

Double width;

AirPressureSensor 0..1 airPressureSensor;

}

class AirPressureSensor {}

}

package vehicles {

class Vehicle {

Wheel 1..* wheels;

}

class Wheel {}

class Car extends Vehicle {

Door 0..* doors;

Engine 1..1 engine;

}

class Engine {}

}

Page 93: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 93

Imagine the same for Text

…and delete from domain model

class Wheel {}

class Car extends Vehicle {

Door 0..* doors;

Engine 1..1 engine;

}

class Engine {}

}

package vehicles {

class AirPressureSensor {}

}

class Wheel {

Double radius;

Boolean tubeless;

Double width;

AirPressureSensor 0..1 airPressureSensor;

}

package vehicles {

class Vehicle {

Wheel 1..* wheels;

}

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?

Page 94: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 94

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

Page 95: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 95

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.

Page 96: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 96

Thank You!

[email protected]

Questions?

Page 97: Axel uhl sap@md-day2011

© 2011 SAP AG. All rights reserved. 98

© 2011 SAP AG. Alle Rechte vorbehalten.

Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind,

zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche

schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation

enthaltene Informationen können ohne vorherige Ankündigung geändert werden.

Die von SAP AG oder deren Vertriebsfirmen angebotenen Softwareprodukte

können Softwarekomponenten auch anderer Softwarehersteller enthalten.

Microsoft, Windows, Excel, Outlook, und PowerPoint sind eingetragene Marken

der Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5,

System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries,

zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390

Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6,

POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes,

BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF,

Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere,

Netfinity, Tivoli und Informix sind Marken oder eingetragene Marken der IBM

Corporation.

Linux ist eine eingetragene Marke von Linus Torvalds in den USA und anderen

Ländern.

Adobe, das Adobe-Logo, Acrobat, PostScript und Reader sind Marken oder

eingetragene Marken von Adobe Systems Incorporated in den USA und/oder

anderen Ländern.

Oracle ist eine eingetragene Marke der Oracle Corporation.

UNIX, X/Open, OSF/1 und Motif sind eingetragene Marken der Open Group.

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.

Java ist eine eingetragene Marke von Sun Microsystems, Inc.

JavaScript ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet

unter der Lizenz der von Netscape entwickelten und implementierten Technologie.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects

Explorer, StreamWork und weitere im Text erwähnte SAP-Produkte und -

Dienstleistungen sowie die entsprechenden Logos sind Marken oder eingetragene

Marken der SAP AG in Deutschland und anderen Ländern.

Business Objects und das Business-Objects-Logo, BusinessObjects, Crystal

Reports, Crystal Decisions, Web Intelligence, Xcelsius und andere im Text

erwähnte Business-Objects-Produkte und Dienstleistungen sowie die

entsprechenden Logos sind Marken oder eingetragene Marken der Business

Objects Software Ltd. Business Objects ist ein Unternehmen der SAP AG.

Sybase und Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere und

weitere im Text erwähnte Sybase-Produkte und -Dienstleistungen sowie die

entsprechenden Logos sind Marken oder eingetragene Marken der Sybase Inc.

Sybase ist ein Unternehmen der SAP AG.

Alle anderen Namen von Produkten und Dienstleistungen sind Marken der

jeweiligen Firmen. Die Angaben im Text sind unverbindlich und dienen lediglich zu

Informationszwecken. Produkte können länderspezifische Unterschiede

aufweisen.

Die in dieser Publikation enthaltene Information ist Eigentum der SAP. Weitergabe

und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem

Zweck und in welcher Form auch immer, nur mit ausdrücklicher schriftlicher

Genehmigung durch SAP AG gestattet.