Model Driven Development

With Borland® Together ® ControlCenter

Tom Gullion <tom.gullion@borland.com>

Product Manager, Together Products
Borland Software Corporation
Agenda
1. Introduction
 Tutorial Description
In this tutorial, we discuss the background
concepts behind model-driven
development and how it relates to
industry trends like MDA. We concentrate
on showing what you can do today and
present a vision for what you'll be able to
do in the future.
Prerequisites: Some experience with UML,
OOAD, and Java.
 Tutorial Goals
Define and describe model-driven
development (MDD)

Describe model-driven architecture (MDA)

We all leave with a somewhat clear picture

of present and future functionality
Model-Driven Development Defined

Models are the focus of development

– not an intermediate work product

Model and Code are of equal importance

– LiveSourceTM is key
• Model and code are always in sync
– “The code is the model, the model is the code”
 LiveSourceTM is key
Model and code are always in sync
Ban on intermediate work products!

Models are the focus of development, not an

intermediate work product

No more stale design documents

No more out-of-date requirements documents

Leverage integrations to always work with “live”

project artifacts!
 MDD/MDA Terms
Model
Platform
CIM
PIM
PSM
Transformations
 Model
Merriam-Webster Online:
• “structural design”
• “a system of postulates, data, and
inferences presented as a mathematical
description of an entity or state of affairs”

Joaquin Miller:
• “Specification of a system and its
environment”
Model Taxonomy
 Platform
general definition
– middleware platforms
• J2EE
• .NET
– OS platforms
• Linux
• Mac OSX
– can be more specific
• BEA WebLogic Platform 8.1
OMG definition
– general approach
OMG definition of “platform”
MDA recognizes that the target "platform" will likely be a
collection of platforms: Linux+JBoss+J2EE+Hibernate+
MySQL+Struts+JSP
 CIM
Computation Independent Model
– Collection of UML diagrams
• Use case, activity, class, state, etc.
– High-level of abstraction
– Color modeling
– Analysis model
 CIM in Together
Separate project vs separate package
• Separate project provides good isolation
– Can be a challenge for traceability
• Separate package partitions ok
– Much better for managing tracability

Configure diagrams to Analysis Detail

- [see ControlCenter]
High-level of abstraction
Reduce complexity
Model the “what” – not the “how”
Visualize collaborations
Form over function
 Color modeling
Peter Coad’s advice:
– Assign colors to categories of classes [diagram
elements]
– ‘Spatial Layering’
– How many colors
• “Five is too many” - Hideaki Chijiiwa (Color Harmony)
– Which colors – Leonardo Da Vinci
• red, yellow, green, blue
– Soften to pastels so text is easy to read
• Pink, pastel yellow, pastel green, pastel blue
– 3M was there before us
• Four color Post-itTM Notes
analysis model
 PIM
Platform Independent Model
– Collection of UML diagrams
• Use case, activity, class, state, etc.
– Always important to define “platform” for
your context
– Independence is relative
• Must specify the platform from which this
model is independent
 PIM
PIM in Together
– design model
– design model with OCL
– color modeling here too
design model
design model with OCL
color modeling here too
 PSM
Platform Specific Model
– Generally specific to
• Some technology;
• A programming language;
• Middleware
• Execution environment
– Typically class diagrams
 PSM in Together
Together’s historic "sweet spot"
can be reverse-engineered too
 Transformations
CIM->PIM
– Biz process model to UML model
PIM->PSM
– the classic design to impl transformation
– Single class to multiple transformation
PIM->PIM
– Analysis to Design transformation
– Object model to ER Logical transformation
PSM->Code
– MDA term for LiveSource
– Model compiler
Transformations (continued)
Model->Model
– Activity diagram to Ant script tranformation
– Interaction diagram to test scripts
Tool Support
– Built-in
• LiveSource Approach
• Deployment Support
• Executable Model Support
– Pluggable
• Provide an API for transformation plug-ins
– Customizable
• Provide an API for transformation plug-ins
 PIM->PIM
Analysis to Design transformation

Object model to ER Logical transformation

 PIM->PSM
the classic design to impl transformation
Single class to multiple classes
transformation
 PIM->PSM

analysis class to EJB collection (EJB +

remote + home interface classes)
 PSM->Code
MDA term for LiveSource
Together does this today…automatically!

Model compiler
 Model->Model
Activity diagram to Ant script transformation

Interaction diagram to test scripts

 Tool Support
Built-in
– LiveSource Approach
– Design Pattern Approach
– Deployment Support
– Executable Model Support
– Export
Pluggable
– Provide an API for transformation plug-ins
Customizable
– Provide an API for transformation plug-ins
2. Practices of MDD
Iterative Devel Defined
"Development is organized into a series of
short, fixed-length mini-projects called
iterations; the outcome of each is a
tested, integrated, and executable
system.“

Craig Larman. Applying UML and Patterns,

Second Edition. Prentice-Hall PTR, 2002
Iterative, incremental…

From Walker Royce,

http://www.sei.cmu.edu/cbs/spiral2000/february2000/Royc
e/
 Benefits
mitigate risks early, rather than late
visible progress
early feedback
manage complexity by breaking up work into
manageable chunks
learning within an iteration can be methodically
used to improve subsequent iterations

Craig Larman, Applying UML and Patterns, Second Edition.

Prentice-Hall PTR, 2002
FDD

Note: two-week timeboxing

Iterative Modeling Guidelines
Don’t have to do it all right now

Freedom to Delete

Avoid intermediate work products

Automate documentation generation

2. Practices of MDD
Modeling Requirements
Plain Text Requirements
Verify Requirements with an Object Model
Visualize Requirements
Model the User Interface
 Plain Text Requirements
The customer’s credit card
is scanned. The system
creates a transaction and
the financial institution
verifies the credit card. If
the credit is declined, an
error logged.
The transaction is finalized
and a receipt is printed.
Finally, the customer
receives their goods.

Note the “miracle” and “black hole”

activities discovered when the narrative
was visually modeled.
Verify Requirements with an
Object Model
Streamlined Object Modeling suggests:

"clients are intimately familiar with details but are stuck in how it is
done now, overlooking potential improvements"

talking about users and user scenarios is bad because it "tends to

bring focus on how the old system worked, not what the real
underlying business process should be."

"Object modeling succeeds because it focuses on the domain

objects and forces everyone in the group to take the object's
viewpoint. Putting people in the same viewpoint is a powerful
technique for gaining group consensus. By contrast, building
scenarios around users compels every participant to consider
the system from his own personal viewpoint, and how he
wants it to work."

"Once the object model is created, then user scenarios are helpful
in fleshing out the "how".'
Visualizing Requirements 1
Visualizing Requirements 2
Visualizing Requirements 3
Visualizing Requirements 4
 User Interface Models

from
Lean Interaction Design
and Implementation:
Using Statecharts with
Feature Driven Development

By David J. Anderson and

Brían O’Byrne
2. Practices of MDD
Modeling Conventions
See Scott Ambler’s BorCon 2004 session!
– read his book or web site:
www.agilemodeling.com/style

Examples:
• Visual layout suggests order
• Naming conventions
• Size matters
• Color modeling
• Model structure
• Traceability
Visual layout suggests
order

perceived time/order
 Naming conventions
The value of naming conventions for code is well-
known.

The same applies for model elements

Consider Ambler’s advice about use case naming:

• Singular
• A role, not a job title
• Don’t start with “process,” “perform” or “do”
Size matters
Color modeling
Model structure
 Traceability
Requirements Traceability links
AND
Together Hyperlinks

Establish norms around when to trace and

what to trace – otherwise it will quickly
become unmanageable – and cease to
be useful…
2. Practices of MDD
 Design Patterns
Stock Patterns
Custom Patterns
Templates
Documenting Pattern Usage
– Better Software Faster suggestion
Pattern Harvesting
– example graphic diagram from designer
 Stock Patterns
Gang of Four
J2EE Design Patterns
Fowler’s EAI Patterns
Web Services Patterns
Etc.
 Custom Patterns
Patterns tailored to your domain
Patterns for your framework(s)
Customized versions of stock patterns
Etc.
 Templates
Together supports two levels of “patterns”
1. SciPattern classes – use Together
ControlCenter’s OpenAPI, written in Java,
highly configurable/extensible
2. Templates – simple token replacement
approach
public class %Name%{
public static void main (String[] argv) {
System.out.println(“%Message%");
}
}
Documenting Pattern Usage
Better Software Faster suggestion
Pattern Harvesting
2. Practices of MDD
Jeff De Luca on Inspections

http://www.featuredrivendevelopment.com/node/view/566

“Inspections are one of the most effective

defect removal techniques. Testing is
one of the least effective defect removal
techniques. We know this from
measurements; it isn't speculation. And
yet, what do most organizations do?
They test. What do most organizations
not do? They don't inspect. Why is this? “
 Automate Low-Level
Inspections
 “Software tools are very effective at finding certain types of
defects… [They] are much faster and more accurate…”
(Gilb, p.12)

 Deep and precise parsing of source

 Saves time and budget
 Separation of concerns:
- Computers excel at low-level inspection and counting
- People do not
- People excel at business logic and design inspection
- Computers do not

Rich Gronback, Software Remodeling

Audits
Metrics
Contemporary Software
Practices
Visual Refactoring
Test-Driven Development

Extreme Programming (XP)

- Continuous code reviews with pair programming
- Produces 85% of the code that should be of substantially
higher quality
Carmichael, Haywood. Better Software Faster.

Feature-Driven Development (FDD)

- Relies heavily on inspections to ensure high quality of
designs and code
- Inspection steps built-in
- Participants limited to those concerned
2. Practices of MDD
 Benefits of Reverse
Engineering
No more stale design documents

Faster ramp up time for new team members

Remove dependence on intermediate work

products

No more lost learning during construction

– Peter Coad’s Gutenberg Dilemma
 Reverse Engineering:
effects on documentation generation

Automated documentation generation is based on

reverse-engineered models

Garbage in, garbage out…

Configurable projects are key

• Set parsing levels
– Dependency checking
– Associations
2. Practices of MDD
 Generators
Generative Programming
Domain Engineering
Product-Line Practices
Usage scenarios
Generators available now
Generative Programming
Generative programming is at the heart of
the concept

Generative programming’s goal is to

move away from single solutions toward
automated manufacturing of varieties of software.

Krzysztof Czarnecki and

Ulrich W. Eisenecker’s book
is required reading
 Domain Engineering
What if you could preserve your past
experiences building software systems?

Domain Engineering does exactly that AND

includes a structure for reusing work
products.
 Conventional vs Domain
Engineering
Software Engineering Domain Engineering
Requirements Analysis Domain Analysis
Produces requirements for one system Produces reusable, configurable
requirements for a class of systems

System Design Domain Design

Produces design of one system Produces reusable design for a class
of systems and a production plan

System Implementation Domain Implementation

Produces system implementation Produces reusable components,
infrastructure and production process

Table 2-4, p57 Generative Programming

Product-Line Practices
Domain Engineering covers
• Development of reusable assets
• Production plan for producing systems reusing
those assets

Product-Line Practices provide

• Management and organization
• Enable Domain Engineering processes
• Provide a feedback loop between them
 Usage scenarios
DTD generator
XSD generator
Entity Relationship Diagrams
– Logical
– Physical
OR Mapping tools
– Including Hibernate (model data specific);
Dialog Generators
– Is it better to wrap a dialog behind an API or generate them?
• Both accelerate development – no more fighting with layout
managers, hand-crafting dialogs to meet UI guidelines, etc.
• Generated don’t require maintaining the API, extending the API
when changes occur, etc….
2. Practices of MDD
 references
www.omg.org
www.uml.org
www.mda.org
www.modelbased.net
www.mdsd.info
http://www.prakinf.tu-ilmenau.de/~czarn/
3. MDA Overview
 What is MDA?
According to the Object Management Group (OMG):
– MDA provides an open, vendor-neutral approach to
the challenge of business and technology change.
– MDA aims to separate business or application logic
from underlying platform technology.
– Platform-independent models can enable intellectual
property to move away from technology-specific code,
helping to insulate business applications from
technology evolution, and further enable
interoperability.
 The Benefits of MDA
Portability
– Insulation from underlying technology change
Productivity
– Code generation
– Communicate visually, thereby reducing complexity
Cross-Platform Interoperability
– Generated bridges
Easier Maintenance and Documentation
– Design artifacts become development artifacts
What Comprises MDA?
MDA is not a single specification, but a collection of related OMG
specifications:
– Unified Modeling Language (UML™) 2.0
• Infrastructure
• Superstructure
• Object Constraint Language (OCL)
• Diagram Interchange
• Profiles
– Meta-Object Facility (MOF)
– XML Meta-Data Interchange (XMI)
– Common Warehouse Meta-model (CWM)
– Query View Transformation (QVT)
MDA Required Reading
Model Driven Architecture:
Applying MDA to Enterprise
Computing
by David S. Frankel

See also
MDA Journal at www.bptrends.com/
 The MDA Logo
Note the industry verticals… MDA is not intended
to be a general purpose model-to-code solution.
 Platform
Platform is a relative concept
According to the MDA Guide:
– “A platform in general is a set of subsystems/technologies that
provide a coherent set of functionality through interfaces and
specified usage patterns that any subsystem that depends on
the platform can use without concern for the details of how the
functionality provided by the platform is implemented.”
Platform Independence
– The quality that the model is independent of the features of a
platform of any particular type.
Platform-Independent Models
– Better called platform computational-independent?
 Transformations
This is the challenge for MDA!
Inspired by existing CWM transformation technology
– MOF2 Core will align basis of UML and CWM
Query, View, Transformation specification is needed
– At present, QVT is MIA

A record of
transformation is
required to maintain
traceability and
synchronization.
 Model Marking
Transformation
Marks are specific to a transformation
– Can be a stereotype in a profile, for example
 The Abstraction Gap
Middleware makes MDA a potential reality
House Person
0..* 1
-value:Money -ssn:Integer
houses owner -salary:Money

+getMortgage(sum:Money,security:House):Mortgage
1 security

1 borrower
Mortgage

-principal:Money
0..* 0..*
-monthlyPayment:Money
mortgages -start:Date mortgages
-end:Date
Abstraction Gap

Today! Level of
Abstraction
Middleware
Practical(ly)
with
3GL with
Generators
Unlikely?
Framework
Middleware
Impractical?
3GL with Operating System
Machine Code with Operating
Impossible?
System
Machine Code
What About SOA and BPM?
Business Process Execution Language for Web Services
(BPEL4WS)
– An XML standard for defining business processes with
Web Services
– Provides high level of abstraction  lends itself to
generation from models
• Negligible abstraction gap
– UML Profile for Automated Business Processes
• Allows UML Class and Activity diagrams to model BPEL
• Generate WSDL, BPEL and XSD Schema
Business Process Definition Metamodel being developed
– UML2-based metamodel with profile for BPD with
mapping to BPEL4WS
 Model and Code
Synchronization
Forward Engineering Only
– The ultimate goal (?)
– Need Action Semantics
– Done in real-time and embedded systems today!
Partial Round-Trip Engineering
– Protected blocks for code
– WYSIWYG GUI tools have done this
Full Round-Trip Engineering
– Changes reflected up and down layers of abstraction
– Necessary to wean programmers off 3GLs?
Building Better Model[er]s
As models move from design artifacts to
development artifacts:
– Casual modelers will need to be upgraded
– Rigorous models required for generation
– Model validation becomes more important
– Model repositories will be needed
 MDA® Summary
MDA is a collection of many specifications
– Many of which are incomplete at present
MDA has promise
MDA is no silver bullet
The jump from 3GLs to MDA is considerably
longer than from Assembly to 3GLs
MDA can be done with agility
– Waterfall not prescribed
MDA will require improved model(er)s
3. MDA Overview
 MDD with Together®
ControlCenter™
Use Design language to model requirements and
domain model (CIM & PIM)
Refine computational portion in PIM package
Export to target language project (e.g. Java, C#,
C++)
Apply design patterns and elaborate design (PSM)
PSM and Code model maintained in sync with
LiveSource™
 Support of the Latest
Standards
Current work in progress:
– UML™ 2 support in development
– OCL 2 support in development
– XMI 2 support in development
– Diagram Interchange support in development
– JMI-based metamodel support (JSR-040)
– Java-based transformation engine for QVT
– UML™ Profile support in development
• Custom profile definition to be supported
 Improving the
Modeling Experience
Look for future support in Together® for:
– Expanded modeling capabilities
• Cater modeling environment to role
• Graphical view of metamodels
– Modeling helpers and tutorials
– Model-level audits and metrics
• Validate models for transformation
– OCL expression validation
– Transformation definition samples for
extensibility
 MDD with Together ®

Tomorrow
Together Together
® ®

Designer Architect
<<include>>

RequirementsCIM Model-Driven Development PIMPSM Transformations

Documentation Generation Design-Driven Development Model Audits & Metrics
Strong CaliberRM integration OpenAPI
Lightweight, standalone modeling Multi-Language, Next Generation
Together ControlCenter
<<include>>

Together®
Developer
PSMCode LiveSource™
Code Audits & Metrics
Embedded IDE Integration
 Industry Support in
modeling & MDA®
Look for future support in Together® for:
– Industry models
• IAA
• eTOM
• etc…
– Industry frameworks
• C4ISR
• Zachman
• etc…
 Model Accessibility
Several possibilities:
– Proprietary metamodel API
– Java™ Metadata Interface (JMI)
• Defined by JSR-040
– Eclipse Modeling Framework (EMF)
• Corresponding UML2 project
Internally, Together® utilizes own metamodel
– Known as “Entity” model
• Full UML2 metamodel implementation unrealistic
– Will be wrapped with standard JMI API for access
• Done with on-the-fly model transformations
 Query View
Transformation (QVT)
No specification available yet
– No standard way to define a
transformation
OMG issued RFP on April 10, 2002
– 8 submissions, with 2 main groups:
• QVT-Merge Group
• Compuware/Sun Microsystems
 Open Source
Transformers
Generative Model Transformer (GMT) http://www.eclipse.org/gmt
– Eclipse project (vaporware, JUUT-je prototype, UMLX 0.0)
– XMI-based (XMI+XMIXMI, XMIXMI, XMItext)
– Transformations based on “textures”
• Patterns specified in unambiguous UML-based format
AndroMDA http://www.amdromda.org
– Builds on XDoclet, utilizes Velocity template engine
– Takes UML XMI file input and generates output using “cartridges”
– Current cartridges: Java, EJB, Hibernate, Struts
– Generates no business logic
Jamda http://jamda.sourceforge.net
– Takes UML XMI file as input, using Jamda profile
– Java-based code generators
• Generated class definitions added to UML model before codegen
• Currently J2EE-centric
Others: UMT-QVT, QVT-Partners; Open Generator FrameWork, etc.
 Model Transformation
Research
OCL-based transformations
– Input and output patterns defined in OCL
– Prolog-based engine
• Identifies input pattern in source model
• Generates output pattern in target model
Rule-based transformations
– Rules declared in XML
– Model access and transform via JMI API
– Batch processing of model, with potential incremental approach
Pattern-based transformations
– Transformation declared with metaclass and OCL
– Traverse modelexamine constraintsapply pattern to target
model
– Technique used in current Together® pattern technology
 Model Validation
Current audits & metrics apply only to source model
– Source Code Interface (SCI) to code model
Model audits use JMI API
– Access and evaluate OCL constraints in model
– Audits themselves can be written in OCL
OCL validator accesses model constraints with JMI API
All validation results utilize common interface
– Unified format for analysis
What you can do now…
Refine your models:
– Leverage UML profiles where appropriate
– Specify all types
– Specify all multiplicities
– Name all associations and association ends
– Clean up “dangling” model elements
– Make models semantically complete
– Declare constraints in OCL
What you can do now…
Treat models as if they were development artifacts
– Not as throwaway design relics
Learn UML2 and OCL
– OMG’s UML2 Certification Program
Avoid UML constructs not supported by MOF:
– N-ary associations
– Qualified associations
– Association classes
Stop hand crafting XSDs, DTDs, and Java APIs for metadata
– Generators exist today!
3. MDA Overview
Overview of Future Support
Support of the Latest Standards
– As they become available…
Improve the Modeling Experience
– Align Products with MDA® Roles & Activities
– Support Industry Models and Frameworks
Increase Generative Capabilities and
Customizability
– Model access, validation, transformation
 Improving the Modeling
Experience

Look for future support in Together® for:

– Expanded modeling capabilities
• Cater modeling environment to role
• Including the ability to get a graphic view of
metamodels
– Modeling helpers and tutorials
– Model-level audits and metrics
• Validate models for transformation
– Transformation definition samples for
extensibility
 MDD with Together®
Tomorrow (first of two)
Current ability of developers to work with PSMs will grow
New capabilities for Analysts with Together Designer
– To create Problem Domain CIMs
– To create models for a library maintained by Architect
PIMs developed with Together Designer
– Can be based on pre-existing Models from Library
– Use OCL2 for constraint definition
– Apply UML Profiles to model
– Rely on model level audits for quality
Code generated maintained in sync with PSM
 MDD with Together®
Tomorrow (continued)
With Together Architect, shops will have model libraries
– Models of Platforms, of Business Process, and Apps
– Ability to combine and transform models
– Access model information programmatically
– Maintain relationships among models
– Define and modify metamodels graphically
Create and maintain libraries of Model Transformations
– A catalog of PIMPSM transformations available
– Define and add your own, or purchase new ones
Validate a service oriented architecture against
– The business process it should automate
 References
D. Frankel, Model Driven Architecture™. Applying MDA™ to
Enterprise Computing. Indianapolis, IN: Wiley, 2003.
S. Mellor et al, MDA Distilled. Principles of Model-Driven
Architecture. Boston, MA: Addison-Wesley, 2004.
A. Kleppe et al, MDA Explained. The Model Driven
Architecture™: Practice and Promise. Boston, MA:
Addison-Wesley, 2003.
J. Miller et al, MDA Guide Version 1.0. Needham, MA: OMG,
2003.
R. Hubert, Convergent Architecture: Building Model-Driven
J2EE Systems with UML. New York, NY: 2002.
4. Questions and Answers