From Business Processes to Running Applications
===============================================
Stefan Tilkov, innoQ Deutschland GmbH
stefan.tilkov@innoq.com
http://www.innoq.com/blog/st/
Agenda
======
* Motivation
* MDA Overview
* MDA Hands-On
* BPM + MDA Vision
* Showcase
Motivation
==========
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
Business and IT Today
=====================
* 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
A Look at Software Development
==============================
* Typical large-scale software development efforts take _years_
* There are different lifecycles for
* projects
* products
* business needs
* technologies & products
Project Lifecycle
=========
* 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
Product Lifecycle
================
* 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
Product Lifecycle (2)
================
* 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
==============
* 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
============
* 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
The Problem: Unsynchronized Lifecycles
==================================
* 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!
The Attempt at a Solution: MDA
===============================
MDA, OMG's Model Driven Architecture, addresses these problems.
Our next task is to find out how.
MDA Overview
============
* Modeling
* MDA concept
* PIM and PSM
* Standards
* Vision and reality
Modeling
========
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 Modeling Problem
====================
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.
The MDA concept
===============
* 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
PIM and PSM
============
* 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 and Other OMG Standards
============================
* MDA is not a standard, but a development paradigm
* Other standards from OMG are re-used:
* MOF
* UML
* XMI
* (CWM)
MOF - Meta Object Facility
==========================
* 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)
Meta-Modeling with MOF
=======================
* 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
===
* 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
UML Metamodel (1)
===================
UML Metamodel (2)
===================
CWM (Common Warehouse Metamodel)
===================
XMI
===
* 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
MDA Vision
==========
* 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
MDA Reality
===========
* 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
MDA in Practice
===============
* 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
Meta-modeling with UML
=======================
* 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
MDA Tool Chain
==============
* CASE tool to create a model and exports XMI
* Code generator that reads XMI and emits (or updates) code
* Development environment
* Runtime platform
Relationships and Overview
===============
MDA Hands-On
============
* Explore MDA capabilities
* Generate applications
* Change models, regenerate
* Change transformation, regenerate
The Tool Set
============
* SparxSystems Enterprise Architect
* innoQ iQgen
* BEA WebLogic Server 8.1 SP3
* MySQL Database Server
* Apache Ant
Example UML Profile
===================
For simplicity's sake, we'll stick to the basics:
* Class Diagram with
* Classes
* Associations
Class Diagram / Classes
=======================
* Persistent objects
* Classes with Stereotype `<>`
* Attributes are persistent
* Facades (Session Beans)
* Classes with Stereotype `<>`
* Persistent objects are assigned to the facade with a directed association of the stereotype `<>`
Class Diagram / Associations
============================
* Associations between `<>` classes
* Directed links with named target roles
* Cardinalities "to 1" and "to Many"
Business Process Modeling
=========================
* 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
BPM and IT
==========
* 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
Vision
======
* 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
Method
======
* 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
Things to do
============
* 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