Transcript Model Driven Development - Embarcadero Technologies

Model Driven Development
With Borland® Together ® ControlCenter
Tom Gullion <[email protected]>
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/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
perceived time/order
Naming conventions
The value of naming conventions for code is wellknown.
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
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 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
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
Person
House
0..*
1
-value:Money
houses
1
owner
-ssn:Integer
-salary:Money
+getMortg age(sum:Money,security:House):Mortgag e
security
1
borrower
Mortgage
0..*
mortgag es
-principal:Money
-monthlyPayment:Money
-start:Date
-end:Date
0..*
mortgag es
Level of
Abstraction
Abstraction Gap
Today!
Middleware
with
Practical(ly)
Framework
Unlikely?
3GL with Middleware
Impractical?
3GL with Operating System
Impossible?
Machine Code with Operating System
Machine Code
Generators
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
®
Together
MDD with
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
RequirementsCIM
Documentation Generation
Strong CaliberRM integration
Lightweight, standalone modeling
®
<<include>>
Architect
Model-Driven Development
Design-Driven Development
<<include>>
Together®
Developer
PSMCode LiveSource™
Code Audits & Metrics
Embedded IDE Integration
PIMPSM Transformations
Model Audits & Metrics
OpenAPI
Multi-Language, Next Generation
Together ControlCenter
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
http://www.eclipse.org/gmt
Generative Model Transformer (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
http://www.amdromda.org
AndroMDA
– 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