Transcript ArcStyler Cartridge Architecture

THE IT-ARCHITECTURE PROFESSIONALS
MDA Discussion Overview
Axel Uhl
© Interactive Objects Software – [email protected]
Agenda
2
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
References
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

3
MDA and the Architectural IDE: High ROI
Change Platforms 2 & 1
Deployable Infrastructure
on Target Platform,
Completely Specified.
Rework
effort w/ high-end
Architectural IDE
(extent of convergent metamorphosis)
Content Level
Complete
Systems
Effective representation
(modeling styles) and
automation begins in
higher P-stacks:
Manual
Rework
Lines
Rework
effort w/o high-end
Architectural IDE
MDA automation lines
$ ROI with each
and every
change!
Effective representation
and automation begins at
lower P-stacks.
a.k.a. The MDA “Phase Diagram”.
From iO’s OMG MDA submission Dec. 2001
Whiteboard
Sketches
PIM -> PSM “P-stacks”
P-stack 4
P-stack 3
P-stack 2
P-stack 1
© 2002, Interactive Objects GmbH
4
The Challenge of Enterprise Java (.NET, z/OS…)
Number of pages in specification
Widening scope
1800
JAAS
1600
Connector
JAXP
JavaMail
JTA
JMS
1400
1200
JSP
1000
Servlets
800
JDBC
600
400
200
EJB
0
J2EE 1.0
J2EE 1.1
J2EE 1.2
J2EE 1.3
5
Takes the path of lowest effort & risk each time


Detailing at low abstraction level causes extra effort and errors.
Example: Associations between EJB components
6
Models, Metamodels, and the Platform Stack
instance_of
Model
1
+describes
Metamodel
1..n
Standards:
- UML
- standardized
UML profiles
- XMI
- Progr.
Languages
Standard:
- MOF
Platform
1..n
0..1
Standards:
- CORBA
- J2EE
- .NET
- Linux
- Windows
implemented_with
+realizedOn
1..n
PlatformRealization
PrimitiveRealization
ComposedRealization
7
The Heart of MDA: Mapping Models
instance_of
1
Model
8
+describes
Metamodel
1..n
1..n
1
+target
+source
1..n
+source
Platform
0..1
1
+t arget
terminology: mapping =^ transformation
Mapping
application_of
MappingTechnique
1
Specification / implementation getting standardized by
MOF 2.0 Query / View / Transformation RFP.
Implementation also called "Cartridge".
Multiple mappings may be applied successively in a chain
Representing Models: Some Examples
9
editable
UML Graphical
Notation
ASCII
representation
UML textual
notation syntax
UML textual
notation syntax
UML
UML
UML Profile for
"EJB Compact Bean"
programmatically
accessible
UML Graphical
Notation
ASCII
EJB Compact
Bean
UML Profile
for JSR 26
EJB Expanded
Bean (JSR 26)
metamodels
ASCII
Java Syntax
Java Abstract
Syntax Tree
Formal: Mapping Techniques for Representations
10
conforms_to
Model
0..1
Metamodel
+abstractSyntax
+represent ingModel
0..n
1..n
+source
Example: UML Profile
0..n
renders
+targetMappingTechnique
MappingTechnique
0..n
+representedModel
0..1
Model
conforms_to
+sourceMappingTechnique
1
0..1
+abstractSyntax
Metamodel
+t arget
Keeping The Model Platform-Independent
terminology: annotation =^ marking
Unannotated PIM
Unannotated PIM
annotations
for platform A
annotations
for platform B
Unannotated PIM
annotations
for platform A
annotations
for platform B
Unannotated PSM
Platform A
Unannotated PIM
annotations
for platform A
annotations
for platform B
Unannotated PSM
Platform B
11
Annotations for Specific Mapping Techniques
+model
Model
+target
+sourceMapping
1
1..n
0..n
0..n
+abstractSyntax
0..1
conforms_to
+source
+metamodel
Metamodel
+so urce
+target
1
+sourceMappingTechnique
+targetMapping
application_o f
1
Mapping
0..n
1..n
0..n
+targetMappingTechnique
Ma ppin gTe ch ni qu e
+mappingTechnique
+requiringMapping
0..n
0..n
+providingMapping
0. .n
+requi ringMappingTechniq ue
0..n
+providingMappingTechnique
Example: Record of
the transformation
+requiredAnnotation
0..n
0..n
Annotation
+re quiredAn nota tionMo del
+providedAnnotation
instance_of
1
0..n
0..n
+providedAnnotationModel
Annotat ionModel
+annotationModel
0.. n
+annotation
0..*
+annotationModel
12
Refining Mappings Visualized
15
PIM 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?
18
PIM and PSM: Resolving the Dispute
19
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)
Java Program
PIM
PSM
JDK / JVM
Solaris
Linux
Windows
Model 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 / XSLT
 hard-wired
 mostly irreversible (often not possibly without ambiguities)

 MOF-based
target metamodels
rules-based
 hard-wired
 sometimes reversible (when unambiguously possible)

20
Transform. 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)
21
MDA 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
22
MDA Process (cont'd)
[ Executing the MDA Instance ]
 6 Conduct the iterations of the project
 6.1
 6.2
 6.3
 6.4

Add/edit detail in one or more of the
mapping's source models
Add/edit contents of the mapping-specific
annotations to one or more of the mapping's
source models
Verify the model for mappability
Perform the mapping, which results in a new
or changed target model
These three steps can be repeated iteratively /
incrementally
23
Example: 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
24
Cartridge 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 cartridge
 even less reuse across cartridges
 hard to extend
 "design" not scalable for more complex cartridges

25
Cartridge 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

26
Cartridge 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 cartridges
 scales up to very complex cartridges
 eased extensibility
 improved integration into ArcStyler due to consistent cartridges:

 selective artifact generation, progress indication
 cartridge profiling and improved precompilation
27
Generating Cartridges with a Cartridge
28
Cartridge Configuration
Specify base cartridge(s)
 Set root generatable (<<CARATRoot>>)
 Associate utility class

29
Model - 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
30
Grouping Artifacts into Sets
31
Defining Extension Points: Artifact Sections

Modeled artifacts can define fine-grained artifact sections
32
Representing the Source Metamodel
Blueprints correspond with metamodel
elements (Class, Attribute, Operation,
AssociationEnd, ...)
 Blueprint inheritance mimics
metamodel inheritance
 Reuse of whole
inheritance subtrees
by registries

33
Model - Artifact Relationship
This is "where the rubber hits the road"
 Blueprints know the representation
of "their" metamodel elements in
the contexts they are
registered with


Use "protected areas" in
places where refinements
may be applied to results
34
Example: Adding an Artifact to Java2 Cartridge
35
Example (cont'd)
36
Cartridges Developed with this Approach at iO
>30MB UML cartridge models
 ~1700 classes with multiple
rules each
 ~6700 rule
connections (as UML
associations)
 ~22MB Jython sources
generated, 1.5MB of
them manually
refined (<7%)

37
Caveats: MOF Q/V/T Still at the Very Beginning
38
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
Open 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)?

39
Outlook
Development and standardization of domain- / platformspecific metamodels, using MOF
 Development and standardization of mapping techniques
(transformations) between them, using MOF 2.0 Q/V/T

40
THE IT-ARCHITECTURE PROFESSIONALS
MDA Discussion Overview
Interactive Objects Software GmbH
Basler Strasse 65
79100 Freiburg, Germany
http://www.ArcStyler.com/
Tel. [+49] 761 / 4 00 73 - 0
Fax [+49] 761 / 4 00 73 – 73
June 26, 2002
OMG_Orlando.ppt
[email protected]