Model Driven Development - PowerPoint PPT Presentation

1 / 115
About This Presentation
Title:

Model Driven Development

Description:

... Unified Modeling Language (UML ) 2.0 Infrastructure Superstructure Object Constraint Language (OCL) Diagram Interchange Profiles Meta-Object Facility ... – PowerPoint PPT presentation

Number of Views:236
Avg rating:3.0/5.0
Slides: 116
Provided by: TomG186
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com