Model-driven approaches to Why models? large-scale e-business The - PowerPoint PPT Presentation

Agenda Model-driven approaches to Why models? large-scale e-business The anatomy of models From models to code system development Standards and maturity Steve Cook IBM Distinguished Engineer Visiting Professor, UKC The architecture is complex and layered e-business systems are developed in a and almost always involves legacy and large, multi-dimensional space package integration Communications Architecture Distribution Sector Financial Services workflow Message broker Industrial Resources Enterprise Public Buy and Sell and Support Supply management Category

How can we “mass-customize” solutions Various approaches have been tried in this complex space? Reusable Code (Objects and Components) Mass Invention Code is too context-dependent to be very reusable Customization Dynamic Level of abstraction (code) is too fixed and physical It is too difficult to find the part you need Product Change “Knowledge Management” Mass Continuous Production Improvement Representation tends to be in disconnected silos, Stable hierarchical, using text and pictures with no semantics Stored elements have no semantic foundation, and no Stable Dynamic notions of refinement or composition Process Change My thesis Agenda There is a “middle way” which has the potential Why models? to deliver a much greater degree of reuse The anatomy of models This “middle way” is based on modelling as a From models to code fundamental technology Standards and maturity Models: Are a formal representation of some aspect of a system from a particular viewpoint Must be precise, abstract and verifiable Should be easy to understand Must be capable of composition and refinement

There are many kinds of inter-related Each model is constructed from model that apply at many levels elements defined by a meta-model ASSE SS PL AN DE SI GN I M PL E ME NT R UN ASSE SS PL AN DE SI GN I M PL E M E NT R UN Meta-model for language A Meta-model for language B Meta-model for language C Process dimension strategic capabilities Abstraction dimension «instance» «instance» «instance» BUSI NE SS business processes BUSI NE SS What are these arrows? system context Model in language A Model in language B Model in language C functional architecture operational architecture I T I T Models can only be related precisely if A modelling language has three main their languages are related precisely aspects Standard meta-meta-model Modelling language definition «instance» «instance» «instance» Concrete syntax Concrete syntax Abstract syntax Abstract syntax Semantics Semantics Meta-model for language A Meta-model for language B Meta-model for language C «instance» «instance» «instance» Concrete-Abstract Mapping Concrete-Abstract Mapping Abstract-Semantics Mapping Abstract-Semantics Mapping Model in language A Model in language B Model in language C * * * *

A modelling language (meta-model) has A modelling language (meta-model) has three main aspects three main aspects Modelling language definition Modelling language definition Concrete syntax Concrete syntax Abstract syntax Abstract syntax Semantics Semantics Concrete syntax Concrete syntax Abstract syntax Abstract syntax Semantics Semantics Diagrammatic syntax (shapes, connectors, layout etc) Definitions of modelling Concrete-Abstract Mapping Concrete-Abstract Mapping Abstract-Semantics Mapping Abstract-Semantics Mapping Concrete-Abstract Mapping Concrete-Abstract Mapping Abstract-Semantics Mapping Abstract-Semantics Mapping or textual syntax constructs (package, class, link (bnf, xml etc) etc) A modelling language (meta-model) has A modelling language (meta-model) has three main aspects three main aspects Modelling language definition Modelling language definition Concrete syntax Concrete syntax Abstract syntax Abstract syntax Semantics Semantics Concrete syntax Concrete syntax Abstract syntax Abstract syntax Semantics Semantics F : C -> A Definition of semantic domain : the abstract logical Concrete-Abstract Mapping Concrete-Abstract Mapping Abstract-Semantics Mapping Abstract-Semantics Mapping Concrete-Abstract Mapping Concrete-Abstract Mapping Abstract-Semantics Mapping Abstract-Semantics Mapping space in which the models find their meanings

A modelling language (meta-model) has A standard meta-meta-model should fully support three main aspects the precise definition of modelling languages Definition of concrete syntax(es) (shapes and M : A -> S layout, physical interchange formats) Modelling language definition Definition of abstract syntax (concepts and relationships, well-formedness rules) Concrete syntax Concrete syntax Abstract syntax Abstract syntax Semantics Semantics Definition of semantics (semantics domain) Definition of mappings between domains Concrete-Abstract Mapping Concrete-Abstract Mapping Abstract-Semantics Mapping Abstract-Semantics Mapping Agenda Conventional approaches for mapping models to code are much too simplistic Why models? The anatomy of models Model From models to code Standards and maturity reverse engineering forward engineering Code

Numerous work products must be Abstracting platform differences is produced on the way from requirements necessary, but not sufficient to implementation and operation Reference Architecture Fit/Gap Analysis Platform Independent Model Architecture Overview Diagram Non-Functional Requirements Architectural Template Current IT Environment Recursive Design (Shlaer-Mellor) Service Level Characteristic Analysis Standards Model-Driven Architecture (OMG) Use Case Model Component Model Operational Model Technical Prototype Class Diagram Deployment Unit Viability Assessment System Context Platform Specific Model Performance Model UI Conceptual Model UI Design Guidelines Numerous work products must be A model of the process can be coupled to produced on the way from requirements metamodels for the work products to implementation and operation Each artifact has its M1 own language (or Reference Architecture Fit/Gap Analysis profile) input1 Architecture Overview Diagram Non-Functional Requirements Each transformation Architectural Template involves a (possibly output task partially automated) Current IT Environment Service Level Characteristic Analysis Standards process M3 Use Case Model input2 Component Model Operational Model Technical Prototype Class Diagram Deployment Unit M2 Viability Assessment System Context Performance Model UI Conceptual Model UI Design Guidelines

Agenda Mass-customization requires mature value networks in the industry Why models? The anatomy of models From models to code Standards and maturity Mass-customization requires maturity of The emerging standards in the modelling the development organisation area are UML, MOF, XMI, and CWM UML : Unified Modeling Language and its profiles Mass-customized solutions MOF : Meta-Object Facility Reused models XMI : XML Metadata Interchange maturity CWM : Common Warehouse Metamodel Common methodology, terminology and standards Basic processes (marketing, sales, design, delivery, maintenance, operations)

UML is: UML is positioned in the OMG’s “4-layer architecture” Notation Meta-Object Metametamodel M3 Facility Abstract syntax (metamodel defined using MOF) Well-formedness rules (Object Constraint UML, CWM, Metamodel M2 Language) SPE Semantics (natural language) IDL interface Model M1 My model What I’m User objects M0 modelling MOF is: XMI (XML Metadata Interchange) is: The standard format for interchanging MOF A standard language for describing metadata metamodels and their instances MOF metametamodel (M3) defined in itself It uses XML for the transfer syntax and MOF reflective IDL interfaces for generic interchange format manipulation of metadata Specify XML Document Type Definitions (DTD) to enable MOF to IDL mappings for type-safe manipulation transfer and verification of of metamodel specific information • UML based models (eg. mymodel.xml, using uml.dtd) MOF to XML mapping: OMG XMI (XML Metadata • MOF based metamodels (eg. uml.xml, using mof.dtd) Interchange) specification • Models based on other MOF-based metamodels (e.g. mymodel.xml using cwm.dtd) MOF to Java mapping: Sun JSR-40, JMI (Java Metadata Interchange) XML schema version is in the works

CWM (Common Warehouse Metamodel) UML is in fact a family of languages, all is: built using MOF A standard model for data warehouse metadata “Core”UML management Defined using MOF, interchanged using XMI, and reusing aspects of the UML metamodel UML-CORBA UML-EAI CWM “UML extension” UML-SPE UML-EDOC UML-EJB “UML profiles” The Request for Proposals for UML UML 2 Infrastructure calls for: version 2 has been issued and work is in progress UML 2 Infrastructure Architectural alignment and restructuring UML 2 Superstructure • strict alignment with 4-layer model • make MOF abstract syntax a subset of UML abstract syntax UML 2 Object Constraint Language • restructure the metamodel in order to separate concerns UML 2 Diagram Interchange • identify “semantic variation points” • backwards compatible with XMI 1.x Extensibility • specify profiles • specify “first class extensions”