Model Driven Development

1
Model Driven Development

• With Borland Together ControlCenter
• Tom Gullion lttom.gullion_at_borland.comgt
• Product Manager, Together Products
• Borland Software Corporation

2
Agenda
3
1. Introduction
4
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.

5
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

6
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

7
LiveSourceTM is key

• Model and code are always in sync

8
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!

9
MDD/MDA Terms

• Model
• Platform
• CIM
• PIM
• PSM
• Transformations

10
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

11
Model Taxonomy
12
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

13
OMG definition of platform

• MDA recognizes that the target "platform" will
  likely be a collection of platforms
  LinuxJBossJ2EEHibernate MySQLStrutsJSP

14
CIM

• Computation Independent Model
• Collection of UML diagrams
• Use case, activity, class, state, etc.
• High-level of abstraction
• Color modeling
• Analysis model

15
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

16
High-level of abstraction

• Reduce complexity
• Model the what not the how
• Visualize collaborations
• Form over function

17
Color modeling

• Peter Coads 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

18
analysis model
19
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

20
PIM

• PIM in Together
• design model
• design model with OCL
• color modeling here too

21
design model
22
design model with OCL
23
color modeling here too
24
PSM

• Platform Specific Model
• Generally specific to
• Some technology
• A programming language
• Middleware
• Execution environment
• Typically class diagrams

25
PSM in Together

• Togethers historic "sweet spot"
• can be reverse-engineered too

26
Transformations

• CIM-gtPIM
• Biz process model to UML model
• PIM-gtPSM
• the classic design to impl transformation
• Single class to multiple transformation
• PIM-gtPIM
• Analysis to Design transformation
• Object model to ER Logical transformation
• PSM-gtCode
• MDA term for LiveSource
• Model compiler

27
Transformations (continued)

• Model-gtModel
• 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

28
PIM-gtPIM

• Analysis to Design transformation
• Object model to ER Logical transformation

29
PIM-gtPSM

• the classic design to impl transformation
• Single class to multiple classes transformation

30
PIM-gtPSM

• analysis class to EJB collection (EJB remote
  home interface classes)

31
PSM-gtCode

• MDA term for LiveSource
• Together does this todayautomatically!
• Model compiler

32
Model-gtModel

• Activity diagram to Ant script transformation
• Interaction diagram to test scripts

33
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

34
2. Practices of MDD
35
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

36
Iterative, incremental
From Walker Royce, http//www.sei.cmu.edu/cbs/spir
al2000/february2000/Royce/
37
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

38
FDD
Note two-week timeboxing
39
Iterative Modeling Guidelines

• Dont have to do it all right now
• Freedom to Delete
• Avoid intermediate work products
• Automate documentation generation

40
2. Practices of MDD
41
Modeling Requirements

• Plain Text Requirements
• Verify Requirements with an Object Model
• Visualize Requirements
• Model the User Interface

42
Plain Text Requirements

• The customers 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.
43
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".'

44
Visualizing Requirements 1
45
Visualizing Requirements 2
46
Visualizing Requirements 3
47
Visualizing Requirements 4
48
User Interface Models

• from
• Lean Interaction Design
• and Implementation
• Using Statecharts with
• Feature Driven Development
• By David J. Anderson and
• Brían OByrne

49
2. Practices of MDD
50
Modeling Conventions

• See Scott Amblers BorCon 2004 session!
• read his book or web site www.agilemodeling.com/s
  tyle
• Examples
• Visual layout suggests order
• Naming conventions
• Size matters
• Color modeling
• Model structure
• Traceability

51
Visual layout suggests order

• perceived time/order

52
Naming conventions

• The value of naming conventions for code is
  well-known.
• The same applies for model elements
• Consider Amblers advice about use case naming
• Singular
• A role, not a job title
• Dont start with process, perform or do

53
Size matters
54
Color modeling
55
Model structure
56
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

57
2. Practices of MDD
58
Design Patterns

• Stock Patterns
• Custom Patterns
• Templates
• Documenting Pattern Usage
• Better Software Faster suggestion
• Pattern Harvesting
• example graphic diagram from designer

59
Stock Patterns

• Gang of Four
• J2EE Design Patterns
• Fowlers EAI Patterns
• Web Services Patterns
• Etc.

60
Custom Patterns

• Patterns tailored to your domain
• Patterns for your framework(s)
• Customized versions of stock patterns
• Etc.

61
Templates

• Together supports two levels of patterns
• SciPattern classes use Together ControlCenters
  OpenAPI, written in Java, highly
  configurable/extensible
• Templates simple token replacement approach
• public class Name
• public static void main (String argv)
• System.out.println(Message")

62
Documenting Pattern Usage

• Better Software Faster suggestion

63
Pattern Harvesting
64
2. Practices of MDD
65
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?

66
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

67
Audits
68
Metrics
69
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

70
2. Practices of MDD
71
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 Coads Gutenberg Dilemma

72
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

73
2. Practices of MDD
74
Generators

• Generative Programming
• Domain Engineering
• Product-Line Practices
• Usage scenarios
• Generators available now

75
Generative Programming

• Generative programming is at the heart of the
  concept
• Generative programmings goal is to
• move away from single solutions toward
• automated manufacturing of varieties of
  software.
• Krzysztof Czarnecki and
• Ulrich W. Eiseneckers book
• is required reading

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

77
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
78
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

79
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 dont require maintaining the API,
  extending the API when changes occur, etc.

80
2. Practices of MDD
81
references

• www.omg.org
• www.uml.org
• www.mda.org
• www.modelbased.net
• www.mdsd.info
• http//www.prakinf.tu-ilmenau.de/czarn/

82
3. MDA Overview
83
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.

84
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

85
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)

86
MDA Required Reading

• Model Driven Architecture
• Applying MDA to Enterprise
• Computing
• by David S. Frankel
• See also
• MDA Journal at www.bptrends.com/

87
The MDA Logo

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

88
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?

89
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.
90
Model Marking Transformation

• Marks are specific to a transformation
• Can be a stereotype in a profile, for example

91
The Abstraction Gap

• Middleware makes MDA a potential reality

Level of Abstraction
Generators
A b s t r a c t i o n G a p
92
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

93
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?

94
Building Better Modelers

• 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

95
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

96
3. MDA Overview
97
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

98
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

99
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

100
MDD with Together Tomorrow
101
Industry Support in modeling MDA

• Look for future support in Together for
• Industry models
• IAA
• eTOM
• etc
• Industry frameworks
• C4ISR
• Zachman
• etc

102
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

103
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

104
Open Source Transformers
http//www.eclipse.org/gmt

• Generative Model Transformer (GMT)
• Eclipse project (vaporware, JUUT-je prototype,
  UMLX 0.0)
• XMI-based (XMIXMI?XMI, XMI?XMI, XMI?text)
• Transformations based on textures
• Patterns specified in unambiguous UML-based
  format
• 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
• 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
105
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

106
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

107
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

108
What you can do now

• Treat models as if they were development
  artifacts
• Not as throwaway design relics
• Learn UML2 and OCL
• OMGs 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!

109
3. MDA Overview
110
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

111
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

112
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

113
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

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

115
4. Questions and Answers