On the Evolution of Tools and Languages · ¤SAP AG 2007, Challenges for Industrial Software Development Tools and Languages / Axel Uhl / 10 Modeling FCoding There are many commonalities

On the Evolution ofTools and Languages

Dr. Axel UhlChief Development ArchitectSAP, Office of the CTO

SAP AG 2007, Challenges for Industrial Software Development Tools and Languages / Axel Uhl / 2

Language History


Language History


Language History


“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,” DSLs


Benefits of Adequate Abstractions

migration effort withspecification provided

at abstract, portable levels

BusinessModel

TechnicalModel

Code usingframeworks

Frameworkimplementation

amou

nt o

f spe

cific

atio

n co

nten

t

completespecification

sketches

complete, deployedsystem

replace platform components 2&1

migration effort withspecification providedin platform-specificways

stack of platform components and languages(examples only)

Enabling / cost reduction forarchitecture / platform evolutionoptimization across layers


Improved Development Efficiency

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

Stack of Platforms and Languages

amount of specification content


Approaches to Adequate Abstractions

“We could embed a DSL into a suitable host language.”Works for textual and graphical languages (e.g., Ruby, UML)Are tooling concerns addressed appropriately?How do you restrict the host language infrastructure to use only your DSL?

“Let’s build a new scripting language, and we’ll be doing fine.”But what distinguishes scripting in the first place?

“Ok, so we’re going to use a model-driven approach.”But what’s the difference between an executable model and a piece of code?And where is a graphical syntax more appropriate than a textual one?Is a model transformation or a code generator different from a compiler?Can I debug my models when the system doesn’t behave as expected?Will I remain agile, with powerful refactoring support?

Let’s take a closer look...


Learning from the “Scripting Trend”

Scripting is abouteliminating the compilation step, leading to quick round tripsease of learningease of changegood integration capabilitiesusing flexible type systems to make developer more productive

Blurring boundariesshort compile/run/debug cycles even for compiled languagesJIT compilation (Java byte code native; JSP to Java to byte code; ...)type system qualities (static vs. dynamic vs. duck typing; inference)memory management and bounds checking in compiled languageslifecycle management requirements for scripting solutionsdifficult auto-completion and refactorings in IDEs due to lack of typeinformation


Modeling Coding

There are many commonalities in what we call programminglanguage and modeling language. Both

have abstract and concrete syntaxcan be of rather declarative or imperative naturecan use different types of representation(though we usually think of programming language artifacts as text strings)

strive for adequate abstractions, concern separation and aspect localization

Many issues of classical “programming” also exist for “modeling”physical partitioning of artifactsdependenciesteamwork aspects (change management, versioning, ...)

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


What’s “Modeling?”

Herbert Stachowiak, Allgemeine Modelltheoriehomomorphic representation– A model represents some thing.– Model and thing are connected by a morphism.

abstraction– The model suppresses irrelevant detail and focuses on important aspects.

pragmatics– The model is created for a purpose.

Let’s take a look at some examples...


Model Example: London Tube Map


Model Example: Crash Test Dummy


Misunderstood Pragmatics...


Homomorphisms at Work


Model Example: Mannequin


...because this would be impractical...


Partial Views


Model Example: Scale Models


...and the Wiring Plan as another Partial View


Model Example: Computer Programs

Pragmaticseasily and correctly describe (parts of) a program that a machine can execute

Abstractionomit unnecessary technical detail of underlying platform

Homomorphismlanguage semantics preserved across compilation or during interpretation

ExamplesUML modelBPMN modelprogram in some 3GLprogram in an assembly language


Informal Definition of “Modeling”

Intuitively, we can characterize models assupporting multiple partial viewsthat are connected and kept in syncand which can be mapped, refined and woven into an executable system

The way we tend to design modeling languages and their tools...with an integrating, underlying model repositorywith a separation of concrete and abstract syntaxwith separate generated and sometimes manually refined artifactswhere all have their own life cycle

...several challenges emerge for model-driven development


Lifecycle Issues of Multiple (Graphical) Views

Changing a model through one view may update anotherviews may be versioned and access-controlled artifactsextensions to models may be provided in multiple layers of the system

Changes in graphical views may be for viewing only...toggle expanded/collapsed setting on a diagram entitychange the zoom level and panning position

...but should not necessitate checkout/versioning operationuser may not have the permissions requiredcreation of a new version not justified by minor changes of settings

Logically atomic changes may affect multiple conflict/merge unitscross-partition link addition/removal that is stored on both endsdelete propagation along composition hierarchyneeds to be considered during merge operations

How to display differences and merge conflicts of abstract model inconcrete syntax (and in which)?


Understood for Text Syntaxes


Where to Display Conflicts for Partial Views?


Textual Syntaxes for Models

Overrated graphical notationsdifficult to implement and managemuch semantics in “secondary notation” (grouping, ordering, alignment)turns out to work best “from expert to expert”

We see approaches promoting textual concrete model syntaxwith a model repository in the back“HUTN revived”

Leads to a different set of challengesmanaging “textual layout” (whitespacing etc.)storing and editing unparsable textincrementally parsing while maintaining model element identity

Diff/merge remains difficult for cross-view changes


Other Challenges

Refactoring supportWhere is a decent UML tool with good refactoring for integrated OCL?Where is a decent model transformation tool that helps me refactor my hand-written code after refactoring the model?

Model migration after language evolution / metamodel changefor some reason, language evolution seems to be perceived more necessaryfor “modeling” languages than for others (“language agility”)complicated by the dependency between abstract and concrete syntax whichmay vary independently

Still largely no industrial-strength “model component ware”the best we see is the open source development around and on top of EMFMOF fragmentation hasn’t helpedstandard workbench paradigms don’t support modeling very well yet


The “Babylonian” Problem

Software factories, language workbenches and all...make it easier to create and evolve certain aspects of languages,but we move away from language standards, using only standard meta-languages

A new set of languages for each project?often lacking good specification, documentation, community and support

What about changing teams, maintenance, specification longevity?


Tools & Languages: Factors to Keep in Mind

Number of developers working on a software productmay require good collaborative features (e.g., partitioning, diff/merge)

Size of the softwaremay require good modularization, as well as flexible delivery and deployment options

Supporting tool features enabled bythe language design

auto-completion (“intellisense”),refactoring, static checks, type inferencedebugging capabilities

Don’t forget about model debugging

Learn from the “Scripting Trend”

Life cycle of a piece of softwarefrom small to largefrom local to centralfrom prototype to productfrom one-off to commercial success


The Good News

Language workbenches are gradually “getting there”language design and tool building is getting easier and easierworkbench environments (e.g., Eclipse) work towards improved modelingsupportgeneric capabilities go hand in hand with the trend towards smaller DSLs

Abstract syntax specification converges on MOF+OCLeven though EMF/EMOF/CMOF confuses, fundamentally it‘s about MOFOCL is ubiquitious, with improving infrastructure– editing– incremental evaluation– compiling into an OCL model for better refactoring

Decreasing hype opens our eyes for the essentialsfinally, we can start working on the core issues


Conclusions

Modeling is not too different from coding.

Increasing complexity of UML standard lets small DSLs thrive.

Relevance of graphical notations is overrated.

Generic qualities of “language workbenches” are increasinglyrelevant.

Language “agility” reduces attention to important quality attributesartifact longevity (migration)source/model-level debuggingrefactoring supportteam development support

By and large we’re moving in the right direction. Let’s keep going!


Thank You


Copyright 2008 SAP AGAll Rights Reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may bechanged without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner,WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or othercountries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks orregistered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of theirrespective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the expressprior written permission of SAP AG.

This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies,developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development.Please note that this document is subject to change and may be changed by SAP at any time without notice.

SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other itemscontained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties ofmerchantability, fitness for a particular purpose, or non-infringement.

SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials.This limitation shall not apply in cases of intent or gross negligence.

The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links containedin these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.

Documents

On the Evolution of Tools and Languages · ¤SAP AG 2007, Challenges for Industrial Software Development Tools and Languages / Axel Uhl / 10 Modeling FCoding There are many commonalities