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

Platformgeneral 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 TogetherSeparate 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->PSMthe 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 SupportBuilt-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, From Walker Royce, http://www.sei.cmu.edu/cbs/spiral2000/february2000/Royce/http://www.sei.cmu.edu/cbs/spiral2000/february2000/Royce/

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

perce

ived tim

e/o

rde

r

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 approachpublic class %Name%{

public static void main (String[] argv) {

System.out.println(“%Message%");

}

}

Documenting Pattern UsageBetter 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 RefactoringTest-Driven Development

Extreme Programming (XP)- Continuous code reviews with pair programming- Produces 85% of the code that should be of

substantially higher qualityCarmichael, 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 andUlrich W. Eisenecker’s bookis 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

Produces requirements for one system

Domain Analysis

Produces reusable, configurable requirements for a class of systems

System Design

Produces design of one system

Domain Design

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

System Implementation

Produces system implementation

Domain 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 generatorXSD 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

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.

What is MDA?

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

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)

What Comprises MDA?

MDA Required Reading

Model Driven Architecture:

Applying MDA to Enterprise

Computing

by David S. Frankel

See also

MDA Journal at www.bptrends.com/

Note the industry verticals… MDA is not intended to be a general purpose model-to-code solution.

The MDA Logo

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

Machine Code

Impossible?

The Abstraction GapMiddleware makes MDA a potential reality

Level of Abstraction

Generators

1

0..*

security

mortgages

1

0..*

borrower

mortgages

10..*

ownerhouses

House

-value:Money

Person

-ssn:Integer-salary:Money

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

Mortgage

-principal:Money-monthlyPayment:Money-start:Date-end:Date

Machine Code with Operating System

Impractical?3GL with Operating System

Unlikely?3GL with Middleware

Practical(ly)Middleware with Framework

Today!

A b

s t r

a c

t i o

n G

a p

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®

Designer

PSMCode LiveSource™Code Audits & MetricsEmbedded IDE Integration

PIMPSM TransformationsModel Audits & MetricsOpenAPIMulti-Language, Next GenerationTogether ControlCenter

RequirementsCIMDocumentation GenerationStrong CaliberRM integrationLightweight, standalone modeling

Together®

Architect

Together®

Developer

<<include>>

<<include>>

Model-Driven DevelopmentDesign-Driven Development

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)– Eclipse project (vaporware, JUUT-je prototype, UMLX 0.0)– XMI-based (XMI+XMIXMI, XMIXMI, XMItext)– Transformations based on “textures”

• Patterns specified in unambiguous UML-based formatAndroMDA

– 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– 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.

http://www.amdromda.org

http://jamda.sourceforge.net

http://www.eclipse.org/gmt

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 modelexamine constraintsapply 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 PIMPSM transformations available– Define and add your own, or purchase new ones

Validate a service oriented architecture against– The business process it should automate

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.

References

4. Questions and Answers