THE IT-ARCHITECTURE PROFESSIONALS

MDA Discussion OverviewMDA Discussion Overview

Axel Uhl

© Interactive Objects Software – info@io-software.com

2

AgendaAgenda Motivation for MDA Terminology: Models, Metamodels, Representations,

Mappings, Platforms, PIM/PSM, Annotations (and Related Standards / Technologies)

Model Transformations and Annotations: Facts and Visions (and Related Standards / Technologies)

Specifying / Implementing Standardization Efforts

MDA Process Shaping and executing an MDA Instance

3

ReferencesReferences ormsc/01-07-01 (previous ormsc guide) ormsc/02-04-02 (latest ormsc guide) ormsc/02-01-04 (Interactive Objects Position Paper) MOF 2.0 Queries / Views / Transformations RFP Other papers from http://www.omg.org/mda

4

a.k.a. The MDA “Phase Diagram”. From iO’s OMG MDA submission Dec. 2001

Change Platforms 2 & 1

Reworkeffort w/ high-endArchitectural IDE

P-stack 4 P-stack 3 P-stack 2 P-stack 1

ManualReworkLines

Co

nte

nt

Lev

el(e

xten

t o

f co

nve

rgen

t m

etam

orp

ho

sis)

Complete Systems

WhiteboardSketches

MDA automation lines

PIM -> PSM “P-stacks”

Deployable Infrastructureon Target Platform,Completely Specified.

Effective representation(modeling styles) andautomation begins inhigher P-stacks:

Effective representationand automation begins atlower P-stacks.

Reworkeffort w/o high-endArchitectural IDE

$ ROI with each and everychange!

MDA and the Architectural IDE: High ROI

© 2002, Interactive Objects GmbH

5

EJB

JDBC

Servlets

JSP

JMSJTAJavaMailJAXP

Connector

JAAS

0

200

400

600

800

1000

1200

1400

1600

1800

J2EE 1.0 J2EE 1.1 J2EE 1.2 J2EE 1.3

Widening scope

The Challenge of Enterprise Java (.NET, z/OS…)The Challenge of Enterprise Java (.NET, z/OS…)Number of pages in specification

6

Takes the path of lowest effort & risk each timeTakes the path of lowest effort & risk each time Detailing at low abstraction level causes extra effort and errors. Example: Associations between EJB components

Metamodels / P-Stacks

Content Level

7

Models, Metamodels, and the Platform StackModels, Metamodels, and the Platform Stack

0..1

Model

PrimitiveRealization

Metamodel11instance_of

PlatformRealization

ComposedRealization

Platform

1..n 0..11..n

+describes

1..n+realizedOn 1..n

1..n1..n

implemented_with

Standards:- UML- standardized UML profiles- XMI- Progr. Languages

Standard:- MOF

Standards: - CORBA - J2EE - .NET - Linux - Windows

8

The Heart of MDA: Mapping ModelsThe Heart of MDA: Mapping Models

MappingTechnique

PlatformMetamodel

1..n 0..11..n

+describes

0..1Model 11instance_of

1

+target

11..n

+source

1..n

Mapping

1

+target

11..n

+source

1..n

11

application_of

Specification / implementation getting standardized by MOF 2.0 Query / View / Transformation RFP.Implementation also called "Cartridge".

terminology: mapping = transformation^

Multiple mappings may be applied successively in a chain

9

Representing Models: Some ExamplesRepresenting Models: Some Examples

programmaticallyaccessible

representation

editable

metamodels

UML textualnotation syntax

UML textualnotation syntax

UML Profilefor JSR 26

UML Profile for"EJB Compact Bean"

Java Syntax

EJB CompactBean

EJB ExpandedBean (JSR 26)

UML

ASCII

UML

ASCII

ASCII

UML GraphicalNotation

Java AbstractSyntax Tree

UML GraphicalNotation

10

Formal: Mapping Techniques for RepresentationsFormal: Mapping Techniques for Representations

Model

Model

0..n

0..1

+represent ingModel 0..n

+representedModel 0..1

Metamodel0..1

+abstractSyntax

0..1conforms_to

Metamodel0..1

+abstractSyntax

0..1conforms_to

MappingTechnique

0..n

1..n

+targetMappingTechnique0..n

+source1..n

+target

+sourceMappingTechnique0..n

1

0..n

1

renders

Example: UML Profile

11

Keeping The Model Platform-IndependentKeeping The Model Platform-Independent

Unannotated PIM

Unannotated PIM

Unannotated PIM

Unannotated PIM

annotationsfor platform A

annotationsfor platform B

annotationsfor platform A

annotationsfor platform B

annotationsfor platform A

annotationsfor platform B

Unannotated PSMPlatform A

Unannotated PSMPlatform B

terminology: annotation = marking^

12

Annotations for Specific Mapping TechniquesAnnotations for Specific Mapping Techniques

Mapping Ma ppin gTe ch ni qu e1

+mappingTechnique

1application_o f

Model

1..n

0..n

+source1..n

+targetMapping0..n

1

0..n

+target 1

+sourceMapping0..n

Annotation

0..n

+model

+annotation

0..n

0..n

0..n

+requiredAnnotation 0..n

+requiringMapping0..n

0..n

0..n

+providedAnnotation0..n

+providingMapping0..n

Metamodel

1..n

0..n

+so urce

1..n

+targetMappingTechnique0..n

1

0..n

+target1

+sourceMappingTechnique 0..n

0..1

+abstractSyntax

0..1conforms_to

Annotat ionModel

0..n

0. .n

+re quiredAn nota tionMo del0..n

+requi ringMappingTechniq ue 0. .n

0..n

0..n

+providedAnnotationModel0..n

+providingMappingTechnique0..n

1

+annotationModel

1instance_of

0..*0..*

+annotationModel

+metamodel

Example: Record ofthe transformation

15

Refining Mappings VisualizedRefining Mappings Visualized

18

PIM and PSM: The Endless DebatePIM and PSM: The Endless Debate PIM: Platform Independent Model

What is a platform? Is a (vertical) domain a platform? Do platforms have to be executable? What platform(s) is a PIM independent of? How can you call a PIM "platform independent" if it eventually

needs one to run on? PSM: Platform Specific Model

What platform(s) is a PSM specific to? Can a PSM be PIM with regard to other platforms?

19

PIM and PSM: Resolving the DisputePIM and PSM: Resolving the Dispute A model can be PIM and PSM at the same time. PIM and PSM are roles a model can assume with regard

to a specific (set of) platform(s). Platforms can be seen as specific domains Example:

A Java program is a PIM with regard to the operating system platforms that Java runs on.

A Java program is a PSM with regard to the programming language and API platform (the JDK)

JDK / JVM

Solaris Linux Windows

Java Program PSM

PIM

20

Model Transformations: Facts and VisionsModel Transformations: Facts and Visions MOF as basis for metamodels becomes common. Exception: ASCII-based target "metamodels". Specification of transformations varies

ASCII-based target metamodels templates mixed with scripting (akin to JSP approach)UML-based (ArcStyler / CARAT)XML / XSLThard-wiredmostly irreversible (often not possibly without ambiguities)

MOF-based target metamodels rules-basedhard-wiredsometimes reversible (when unambiguously possible)

21

Transform. Spec.: Requirements and CriteriaTransform. Spec.: Requirements and Criteria(partly taken from MOF 2.0 Queries, Views, and Transformations RFP, and from ormsc/02-04-02): reusability extensibility scalability (for large metamodels) handling complexity efficiency (for large models) incremental applicability (transforming changes only) reversibility (where possible)

22

MDA ProcessMDA Process

[ Instantiating the MDA ] 1 Identify the set of target platforms 2 Identify the metamodels you want to use 3 Define the mapping techniques between

the metamodels 4 Define the annotation models required by

the previously defined mapping techniques

5 Implement the mapping techniques

23

MDA Process (cont'd)MDA Process (cont'd)

[ Executing the MDA Instance ] 6 Conduct the iterations of the project

6.1 Add/edit detail in one or more of the mapping's source models

6.2 Add/edit contents of the mapping-specific annotations to one or more of the

mapping's source models 6.3 Verify the model for mappability 6.4 Perform the mapping, which results in a new

or changed target model These three steps can be repeated iteratively /

incrementally

24

Example: Cartridge Development at iOExample: Cartridge Development at iO three years of profound, hands-on experience projects and product (ArcStyler) from CRC cards via UML to J2EE technologies, CORBA,

host-based environments (COBOL, XML adapters, ...) went through three generations of cartridge architectures productized cartridge extensibility since ArcStyler 1.0 customers using it in real-world projects

But: Still some issues to be solved

25

Cartridge Architecture History at iOCartridge Architecture History at iO ArcStyler 1.x w/ CARAT 0.0

template files weaving in JPython script parts with plain text large "flat" JPython function libraries with little structure master.tpl and iterator.py controlled generation process Pros:

templates correspond closely with output Cons:

little reuse within single cartridgeeven less reuse across cartridgeshard to extend "design" not scalable for more complex cartridges

26

Cartridge Architecture History at iOCartridge Architecture History at iO ArcStyler 2.x w/ CARAT 1.0

using OO to structure cartridges into classes and objects inheritance possible between whole cartridges complete re-write of cartridges, beginning with IAS/BAS Pros:

significantly increased reuse within and across cartridges improved design, geared towards extensibility

Cons:generated output harder to recognize in templates tricky wiring of cartridge elements (who triggers what, ...)hard to get a grip on how the pieces work together

27

Cartridge Architecture History at iOCartridge Architecture History at iO ArcStyler 3.x w/ CARAT 2.0

cartridges modeled using CARAT-specific meta-model with corresponding UML profile

generate cartridge impl. using CARAT cartridge, fill in PAs Pros:

practice what you preach: reaps MDA benefits for cartridge devel.comparatively easy visual configuration of cartridgesscales up to very complex cartridgeseased extensibility improved integration into ArcStyler due to consistent cartridges:

selective artifact generation, progress indication cartridge profiling and improved precompilation

28

Generating Cartridges with a CartridgeGenerating Cartridges with a Cartridge

29

Cartridge ConfigurationCartridge Configuration Specify base cartridge(s) Set root generatable (<<CARATRoot>>) Associate utility class

30

Model - Artifact RelationshipModel - Artifact Relationship What we have

UML business model representing some functionality What we want (for model to code transformations)

Physical artifacts executing this functionality within an IT infrastructure, e.g. Java classes in a JVM

31

Grouping Artifacts into SetsGrouping Artifacts into Sets

32

Defining Extension Points: Artifact SectionsDefining Extension Points: Artifact Sections Modeled artifacts can define fine-grained artifact sections

33

Representing the Source MetamodelRepresenting the Source Metamodel Blueprints correspond with metamodel

elements (Class, Attribute, Operation, AssociationEnd, ...)

Blueprint inheritance mimics metamodel inheritance

Reuse of wholeinheritance subtreesby registries

34

Model - Artifact RelationshipModel - Artifact Relationship This is "where the rubber hits the road" Blueprints know the representation

of "their" metamodel elements inthe contexts they areregistered with

Use "protected areas" inplaces where refinementsmay be applied to results

35

Example: Adding an Artifact to Java2 CartridgeExample: Adding an Artifact to Java2 Cartridge

36

Example (cont'd)Example (cont'd)

37

Cartridges Developed with this Approach at iOCartridges Developed with this Approach at iO >30MB UML cartridge models ~1700 classes with multiple

rules each ~6700 rule

connections (as UMLassociations)

~22MB Jython sourcesgenerated, 1.5MB ofthem manuallyrefined (<7%)

38

Caveats: MOF Q/V/T Still at the Very BeginningCaveats: MOF Q/V/T Still at the Very Beginning

MDA tools are now ready for prime-time. We should apply them in order to

not to abstract from 0 to n, standardizing prematurely make sure a standard is built on solid, profound

experience from real-world projects allow for diversity of approaches before validation and

consolidation takes place

39

Open Issues Regarding TransformationsOpen Issues Regarding Transformations How can manual refinements in non-ASCII target models

be supported? "Protected Areas" defined on MOF-specified metamodels techniques to detect manual refinements in such areas

How to reverse-enable transformation fan-out? How to combine reversibility with extensibility? How do different approaches handle large-scale

transformations? How to derive an implementation from the specification

(we can do ~93% for model-to-code today)?

40

OutlookOutlook Development and standardization of domain- / platform-

specific metamodels, using MOF Development and standardization of mapping techniques

(transformations) between them, using MOF 2.0 Q/V/T

THE IT-ARCHITECTURE PROFESSIONALS

Interactive Objects Software GmbHBasler Strasse 6579100 Freiburg, Germany

Tel. [+49] 761 / 4 00 73 - 0Fax [+49] 761 / 4 00 73 – 73

info@io-software.com

MDA Discussion Overview

http://www.ArcStyler.com/

June 26, 2002OMG_Orlando.ppt