December 2004

Stefan Tilkov, innoQ Deutschland GmbH

[email protected]

http://www.innoq.com/blog/st/

• Motivation
• MDA Overview
• MDA Hands-On
• BPM + MDA Vision
• Showcase

Hopefully, we're doing all this for good enough reasons. Let's take a look at them.

• Business and IT today
• A look at software development
• Projects, products, business needs, and technology

• Businesses face the need for adapting fast
• New opportunities require flexibility
• IT systems need to enable, not hinder, change
• IT is becoming more and more important

• Typical large-scale software development efforts take years
• There are different lifecycles for
  • projects
  • products
  • business needs
  • technologies & products

• Typical software systems evolve through
  • requirements engineering
  • analysis
  • design
  • implementation and
  • test

• Analysis and design are largely technology-independent
• Might be (and should be) done iteratively/incrementally
• Agile methods don't change this fundamentally
• A project is by definition something with a beginning and an end

• A product -- even an internal one -- is a system with multiple releases
• The building of a release is usually done within a project
• For a particular product, there might be one release in development and another one in maintenance

• A product lifecycle contains
  • the initial project idea
  • budgeting, make-or-buy analysis
  • release planning (possibly)
  • repeatedly
  • projects
  • deployment
  • operation
  • migration
  • parallel operation
  • phase-out

• Overall, a product may live for 10, 20 or even 30 years

• Business needs (or business models) change due to
  • changing markets
  • aquisitions and mergers
  • new strategies
  • investor priorities

• Changing business requirements is a totally unpredictable process

• Technologies get introduced, become popular, over-hyped, useful and obsolete
• Recent examples include RPC, CORBA, J2EE, Web Services
• Products are upgraded to new versions 1 to 2 times per year
• major trends change every 2-5 years

• All of these cycle at different speed
• Systems capture a specific state of multiple interlocked cycles
• One can't be changed without affecting the other
• Even the coolest technology can become outdated within the life of a product
  • sometimes even within one project!

• BUT: Just because there's a new technology that'd be cool to use, you can't afford to throw everything away!

MDA, OMG's Model Driven Architecture, addresses these problems. Our next task is to find out how.

• Modeling
• MDA concept
• PIM and PSM
• Standards
• Vision and reality

Let's re-iterate what we're modeling for:

• A model is an abstraction that enables to reason about something with less complexity
• A business model is independent of any particular technology
  • In theory, at least

• The goal of modeling is to come up with models that help us to
  • have something both business and IT people can understand
  • can be used for efficient communication between project staff and stakeholders
  • documents what the system does at a high level

The problem with models is that they're usually not in sync with the system.

• Developers find out the analysts/designers were wrong
• The system evolves and the model is not updated
• Requirements changed and are channeled through directly to implementation

A model that is not correct may be worse than no model at all.

• Give models a new, extremely important role
• Let them be the initial input for formalized and automated development
• change your development process architecture so that it is model-driven

• A PIM, a Platform Independent Model, captures the business design
• A PSM, a Platform Specific Model, targets a specific platform
• A PIM is turned into one or more PSMs via transformations or mappings

• MDA is not a standard, but a development paradigm
• Other standards from OMG are re-used:
  • MOF
  • UML
  • XMI
  • (CWM)

• Standard 4-level (M0-M3) meta-modeling concepts
• Separated from UML in 1.x, common foundation in 2.x
• Most popular (EMOF) incarnation in Eclipse Modeling Framework (EMF)

• For a specific problem domain, a specific language is created
• This is done by means of a meta-model
• Tools, such as repositories, may support MOF meta-models
• Domain descriptions are models (instances of the meta-model)

• UML is one general purpose domain-specific, MOF-compliant modeling language
• It covers (almost) every known facet of object-oriented software development
• Contains Action Semantics - a Turing-complete "programming language"
• UML contains (limited) customization/extensibility facilities

• XMI (XML Metadata Interchange) is an XML language for exchanging MOF/UML models
• Supported by every CASE tool vendor
• Used to enable inter-operability between tools from the same or different vendors
• In theory, there's no difference between theory and practice

• There is a market for pre-defined mappings for standard platforms, such as .NET or J2EE
• Models can be interchanged and re-used across different platforms
• Business designers model systems, programming is done automatically
• Everything is contained in models

• 100% system design via modeling is not universally accepted
• Exception: Specific domains, such as Real-Time/Command & Control
• Nearly all tools and approaches follow the "MDA light" pattern

• Modeling is used where it is more productive than programming (typically, but not only, for structural aspects)
• The modeling language is UML
• Transformation of models to implementation is done via code-generation (no model-to-model transformation)
• Algorithms and business logic are implemented in the programming language of choice

• UML supports profiles as a substitute for "real" meta-models
• A profile customizes ("tailors") the UML to suit specific needs
• The profile specifies stereotypes and tagged values that can be applied to model elements
• CASE tools differ in their support for enforcing rules

• CASE tool to create a model and exports XMI
• Code generator that reads XMI and emits (or updates) code
• Development environment
• Runtime platform

• Explore MDA capabilities
• Generate applications
• Change models, regenerate
• Change transformation, regenerate

• SparxSystems Enterprise Architect
• innoQ iQgen
• BEA WebLogic Server 8.1 SP3
• MySQL Database Server
• Apache Ant

For simplicity's sake, we'll stick to the basics:

• Class Diagram with
  • Classes
  • Associations

• Persistent objects
  • Classes with Stereotype <<entity>>
  • Attributes are persistent

• Facades (Session Beans)
  • Classes with Stereotype <<facade>>
  • Persistent objects are assigned to the facade with a directed association of the stereotype <<uses>>

• Associations between <<entity>> classes
  • Directed links with named target roles
  • Cardinalities "to 1" and "to Many"

• Business process modeling is usually not done with an IT focus
• Stakeholders are business people, not IT folks
• Models exist at different levels of abstraction

• Business Processes are mapped to IT systems with varying degrees (depending on the industry)
• There are numerous way to make use of business process models:
  • For documentation purposes
  • As an information/change impact analysis tool
  • Strategic planning
  • To drive a BPM engine

• We are going to explore how to marry BPM to MDA

• Enable a consistent modeling approach from the highest to the lowest level
• Different views/different levels of abstraction
• Manual, semi-automated, fully-automated transformation
• Bridge the gap between business models and IT models

• Model business process as an Aris eEPC
• Export process definition to CASE tool
• Enrich model with IT-related, platform-independent information
• Generate application based on pre-defined transformations
• Refine application

• Extend the UML profile and the templates to support
  • Controls with labels, optionally including internationalization support
  • visual and tab order of controls in views
  • re-generation of views after modification

• Generate JPDs from activity diagrams
• Integrate WL Workshop into the tool chain
• Integrate alternative backends, e.g. Hibernate or JDO