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