Modellierung operationaler Aspekte von Systemarchitekturen Master Thesis presentation October 2005 March 2006
Agenda Goals Model-Driven Software Development Pro-active Infrastructure (PAI) Operational Aspects PAI Operational Model DSL for the Operational Model Model Transformations Implementation with Eclipse Tools Demo Conclusion References 2
Goals Analyse modeling approaches for operational aspects Evaluate existing technology for domain-specific modeling Implement prototype modeling solution 3
Agenda Goals Model-Driven Software Development Pro-active Infrastructure (PAI) Operational Aspects PAI Operational Model DSL for the Operational Model Model Transformations Implementation with Eclipse Tools Demo Conclusion References 4
Model-Driven Software Development Goals: Reduce software development time Reduce software complexity Increase software quality Increase software reusability Key aspects: Use models as primary development artifacts based on DSL Transform abstract models into less abstract models (or source code) Provide Infrastructure (tools, processes, components) 5
Model-Driven Software Development Main paradigms: Model-Driven Software Development Use abstract but formal models based on DSLs Use transformations to generate less abstract models or code Model-Driven Architecture (MDA) Standardization of Model-Driven Software Development by OMG Usage of OMG standards (MOF, UML, XMI, OCL, QVT) Focus on interoperability and portability Software Factories Microsofts vision of Model-Driven Software Development Rejects OMG standards, uses own DSL Metamodel Focus on tooling support 6
Model-Driven Software Development Code of the application reference implementation analyse Individual code Generic code Schematic and repeating code separate Application model Application model Application model Schematic Schematic and and Schematic repeating repeatingand code code repeating code Individual code Individual code Individual code DSL Transformations Platform uses creates 7
Model-Driven Architecture Technical Specification PIM (via UML-Profile) Model-to-Model Transformation CORBA-Model J2EE-Model XML-Model PSM (via UML-Profile) Model-to-Code Transformation CORBA / C++- Code J2EE / Java- Code XML-Code Implementation 8
Agenda Goals Model-Driven Software Development Pro-active Infrastructure (PAI) Operational Aspects PAI Operational Model DSL for the Operational Model Model Transformations Implementation with Eclipse Tools Demo Conclusion References 9
Pro-active Infrastructure Pro-active Infrastructure is a DCX standardized IT infrastructure foundation to optimize the development and in particular the operations of custom applications within the DaimlerChrysler group. 10
Pro-active Infrastructure Before the usage of PAI After the usage of PAI Application Application SUN JES Directory WebSphere Application Server PAI J2EE CA Siteminder IBM HTTP Server PAI Directory PAI Security DCX Infrastructure (Network, Firewalls, Proxy Server, BGN, etc.) DCX Hardware/OS Infrastructure Infrastructure & Middleware integration issues need to be addressed on an application project level Standardized, Integrated & Release Managed Platforms for all application projects to minimize complexity and provide standardized solutions. 11
Pro-active Infrastructure Application Platforms.NET Application Platform Notes Application Platform NetWeaver Application Platform Application Integration Platforms Collaboration Platform NetWeaver Process/People Integration Data Integration Platforms Business Intelligence Platform Data Management Platform NetWeaver Information Integration Shared Services Platforms Authentication Directory Service* Content Management Platform Operation Services Platform *provided by PAI Security and Directory Providers 12
Agenda Goals Model-Driven Software Development Pro-active Infrastructure (PAI) Operational Aspects PAI Operational Model DSL for the Operational Model Model Transformations Implementation with Eclipse Tools Demo Conclusion References 13
Operational Aspects Software Architecture is devided into two categories: Functional Aspects Operational Aspects - Structures of software components - Interaction between components - Definition of interfaces - Dynamic behaviour of components - Network organisation - Distribution of components - Service level requirements - Systems Management IBM Architecture Description Standard defines conventions for notation, terminology and semantics for the architecture of an IT system 14
Operational Aspects Developed software IT infrastructure Configuration files, deployment descriptors, etc? Server Daten Mainframe Software components Server Software architecture and design IT infrastructure? Server Daten Mainframe Server 15
Operational Aspects Vital for the developement and operation of large scale applications Need to be addressed in all phases of software development: Requirements: - Operational requirements - Non-functional requirements Design: - Distribution of components - Design for non-functional requirements Test: - Set up test environment - Test functional and non-functional Requirements Implementation: - Implement for non-functional requirements - Implement operational Features Operation: - Deploy and configure software - Maintain and manage software 16
Agenda Goals Model-Driven Software Development Pro-active Infrastructure (PAI) Operational Aspects PAI Operational Model DSL for the Operational Model Model Transformations Implementation with Eclipse Tools Demo Conclusion References 17
PAI Operational Model Operational Model (OM) used for operational aspects within PAI: Part of IBM Global Services Method Defines: Contains: Distribution of components over Nodes of the IT infrastructure and the Connections required for the interactions of the components in order to archieve Functional and non-funtional requirements One or more relationship diagrams One or more walktrough diagrams Detailed description of nodes and connections Description of how functional and non-functional requirements will be met Description of the systems management strategy Devided into two / three different levels of abstraction 18
PAI Operational Model abstraction Operational Model Conceptual Level Levels of abstraction for Operational Model Operational Model Specification Level Operational Model Physical Level time 19
PAI Operational Model Operational Model Conceptual Level Operational Model Specification Level Operational Model Conceptual Level (CL) defines the set of conceptual nodes (CN) and functional relations between them specifies the zoning defines deployment units (DU) for each CN no product information, no physical specifications Operational Model Physical Level 20
PAI Operational Model CN_CO_Browser CN_J2EE_WebServer A_User E_WebBrowser E_JavaRuntime CN_J2EE_RichClient E_J2EE_RichClientRuntime E_JavaRichClientApp E_JavaRuntime CC_002 CC_001 CC_019 E_WebServer E_AppServerPlugin E_PolicyServerWebAgent U_J2EE_WebServerIntegration I_J2EE_RichClientRuntime I_J2EE_RichClientExample I_JavaRichClientApp Z_DMZ CC_006 To arbitrary Web Applications A_Administrator Z_User CN_CO_Browser E_WebBrowser Z_Administrator CC_063 CC_066 CC_010 CN_J2EE_DeploymentManager E_AppServerDeploymentManager D_ AppServerDMgrConfiguration D_ AppServerConfiguration E_J2EE_RuntimeExtensions D_ J2EE_DMgrRuntimeConfiguration E_J2EE_SecurityIntegration D_ J2EE_SecurityConfiguration D_ SecurityPropertyConfiguration D_ SecurityPolicyServerDMgrConfiguration D_ LoggingDataConfiguration I_J2EE_IntegrationTest I_J2EE_SecurityIntegration I_J2EE_SecurityIntegrationTest I_J2EE_DataExchange I_J2EE_RichClientServer I_J2EE_RichClientServerExample I_J2EE_ThinClientServerExample I_J2EE_MessagingIntegration I_J2EE_MessagingIntegrationTest I_Application Z_Deployment CC_064 CN_J2EE_AppServer E_AppServer E_AppServerTest E_DatabaseClient E_J2EE_RuntimeExtensions D_J2EE_RuntimeConfiguration E_J2EE_IntegrationTest E_J2EE_SecurityIntegration E_J2EE_SecurityIntegrationTest D_SecurityPolicyServerConfiguration E_J2EE_ThinClientServerExample E_J2EE_RichClientServerExample E_J2EE_MessagingIntegrationTest E_Application CC_065 CC_030 CC_032 To arbitrary Applications CC_016 CC_037 CN_J2EE_DatabaseServer E_DatabaseServer D_DataExchangeData D_LoggingData D_SessionData D_ApplicationData Z_Data CN_SEC_PrivilegeServer D_ApplicationPolicies CN_DIR_DirectoryServer D_J2EE_UserData D_J2EE_RichClientUserData D_J2EE_TestUserData D_ApplicationUserData Z_Security. CC_014 CC_012 CC_067 CC_033 CC_034 CN_J2EE_SharedServices E_AppServer E_DatabaseClient E_J2EE_RuntimeExtensions D_J2EE_RuntimeConfiguration E_J2EE_IntegrationTest E_J2EE_SecurityIntegration E_J2EE_SecurityIntegrationTest D_SecurityPolicyServerConfiguration E_J2EE_DataExchange E_J2EE_RichClientServer D_J2EE_RichClientConfiguration E_J2EE_MessagingIntegration D_J2EE_MessagingIntegrationConfiguration Z_Application CC_031 21
PAI Operational Model Operational Model Conceptual Level Operational Model Specification Level Operational Model Specification Level (SL) Specific instance of conceptual level Defines the products and major versions to use Specifies the type of CN s (cluster, HW pattern,..) No hostnames, no information about real instances Operational Model Physical Level 22
PAI Operational Model Z_Administration A_Administrator SN_CO_Browser E_WebBrowser SN_CO_DB_Admin E_DB_Admin SN_CO_RP_LoadBalancer SC_017 A_User A_User SN_CO_Browser E_WebBrowser SN_J2A_Client CN_J2A_JunaClient CN_J2A_JavaClient CN_J2A_JavaThinsClient E_IAP_ClientContainer E_IAP_J2EE_Container E_IAP_ThinClientContainer U_JavaRichClientApp E_JavaRichClientApp E_JavaThinClientApp Z_User SC_001 SC_002 SC_004 E_LoadBalancer SN_CO_RP_LoadBalancer HotStdBy E_LoadBalancer SN_CO_ReverseProxy E_ProxyServer SN_CO_ReverseProxy E_ProxyServer SN_CO_WS_LoadBalancer SC_005 E_LoadBalancer SN_CO_WS_LoadBalancer HotStdBy E_LoadBalancer SC_003 Z_DMZ SC_012 SN_J2A_WebServer CN_J2A_WebServer E_WebServer E_SiteMinderAgent E_WebSpherePlugin E_IAP_WebModule SC_020 SC_019 SC_006 SN_J2A_DeploymentManager E_DeploymentManager SN_J2A_DeploymentManager HotStdBy E_DeploymentManager Z_Deployment SC_007 SC_018 SN_CO_ForwardProxy E_ProxyServer SN_CO_ForwardProxy E_ProxyServer SC_014 SN_CO_FP_LoadBalancer E_LoadBalancer SN_CO_FP_LoadBalancer HotStdBy E_LoadBalancer Z_DMZ SC_008 SC_009 SN_SEC_PrivilegeServer SN_CO_DirLoadBalancer D_SEC_Data E_LoadBalancer SN_DIR_DirectoryServer CN_DIR_DirectoryServer D_DIR_Data... Z_Security. SC_010 SN_J2A_AppServer CN_J2A_WebAppServer CN_J2A_IAP_Server CN_J2A_AppServer E_WAS E_DatabaseClient E_WAS_SecurityIntegration E_IAP_J2A_Runtime E_WebApplication E_J2A_Application Z_Application SC_016 SC_011 SN_J2A_DataBase E_DatabaseServer D_WAS_ConfigData D_ADE_Data D_SESS_Data D_LOGGING_Data D_Application Data Z_Data SC_015 23
PAI Operational Model Operational Model Conceptual Level Operational Model Specification Level Operational Model Physical Level (PL) Defines all aspects required for setting up the environment in a real hosting environment IP s, hostnames, ports, FW Machine specification, references to asset management Operational Model Physical Level 24
PAI Operational Model 25
PAI Operational Model Other operational artifacts: Operational Description (OD): XML-based document Central repository for operational information Contains data from Operational Model of all levels Detailed configuration parameters for base products and PAI components Used for PICS Platform Installation and Configuration Solution (PICS) Automated installation and configuration of PAI J2EE Platform Based on predefined solutions and user-guided wizard Uses OD as major input 26
PAI Operational Model Current state: Operational Model only used in informal way (Visio diagrams, Word files ) No consistency checks possible No standard notation so far for Operational Model Only rarely used by PAI projects (due to lack of tools?) Operational Description for J2EE has around 3000 lines of XML Complex and not human readable Difficult to maintain Modeling approach could solve some problems here! 27
Agenda Goals Model-Driven Software Development Pro-active Infrastructure (PAI) Operational Aspects PAI Operational Model DSL for the Operational Model Model Transformations Implementation with Eclipse Tools Demo Conclusion References 28
DSL for the Operational Model Domain Specific Languages: Used to define the key aspects of a specific domain Enriches models with semantic Captures the knowledge of the domain expert Already widely used (SQL, FORTRAN, etc.) Key item for model-driven software development Ingredients: Abstract Syntax Static Semantic Dynamic Semantic Concrete Syntax Metamodel Model transformations 29
DSL for the Operational Model Metamodeling describes Instance of 4 layers defined by Meta-object Facility (MOF) Java Code on M0 (as instance of UML-model) UML-Models on M1 UML-Metamodel on M2 MOF on M3 Meta-Metamodel describes Instance of Metamodel M3 M2 Possible metamodels for DSL: describes Instance of 1. Extend UML-Metamodel in M2 with profiles (stereotypes, tagged values) 2. Create new M2 metamodel based on MOF 3. Create new M2 metamodel based on other M3 metametamodel describes Model Instance of M1 DSL as new M2 metamodel based on MOF Instances M0 30
DSL for the Operational Model Metamodeling approach: Analyse existing models Extract key elements Model key elements in metamodel Use modeling techniques known from UML modeling Best-practices: Keep it simple Interatively check and extend metamodel against model Model containment in one single element (direct or indirect) 31
DSL for the Operational Model Structure of the Metamodel: Basic Elements Conceptual Level Specified Level Physical Level 32
DSL for the Operational Model Metamodel Basic elements 33
DSL for the Operational Model Metamodel Elements of conceptual level 34
DSL for the Operational Model Metamodel Elements of specification level 35
DSL for the Operational Model Metamodel Elements of physical level 36
DSL for the Operational Model Semantics: Semantics define the meaning of a language Static semantics define the well-formedness of a model Static semantics can be expressed as contraints in the metamodel Dynamic semantics define the meaning of elements of the metamodel Dynamic semantics expressed on forms of transformations 37
DSL for the Operational Model Static Semantic with OCL Object Constraint Language (OCL) is a declarative, side-effect free language for the definition of constraints on a model (or metamodel) Can be applied on M1, M2 or M3 Example for the Operational Model metamodel: context sl::snode inv: self.deploymentunits->select(du not du.supportedoss ->exists(os os.id = self.operatingsystem.id)) ->union( self.deriveddus->select(du not du.supportedoss ->exists(os os.id = self.operatingsystem.id)) ) 38
Agenda Goals Model-Driven Software Development Pro-active Infrastructure (PAI) Operational Aspects PAI Operational Model DSL for the Operational Model Model Transformations Implementation with Eclipse Tools Demo Conclusion References 39
Model Transformations Why model transformations? Capture the semantics of the metamodel Reduce modeling complexity and effort Ensure consistency between models Model Transformations vs. Text Transformations (XSLT) Validation of transformation rules based on metamodel Only valid models are generated Reduced complexity Support for synchronisation of models 40
Model Transformations IBM Model Transformation Framework Based on EMF metamodels Bidirectional Transformations Reconciliation of transformed models Based on RFP on QVT (Query, View, Transformation) Available as Eclipse Plugin 41
Model Transformations Workflow model transformations Transformations Reconciliation Inverse Transformation Initial Transformation Input Action Output Transformation Source model Transformation Target model Mapping Source-Target Modified source model Execute transformation Execute transfomration Reconcile models Mapping source-target Target model Mapping target-source Reconciliated models 42
Agenda Goals Model-Driven Software Development Pro-active Infrastructure (PAI) Operational Aspects PAI Operational Model DSL for the Operational Model Model Transformations Implementation with Eclipse Tools Demo Conclusion References 43
Implementation with Eclipse Tools Eclipse Tooling Landscape: Eclipse: extensible Rich-Client Framework and IDE Eclipse Modeling Framework (EMF): modeling framework and code generation facility for building tools and other applications based on a structured data model Eclipse Graphical Editing Framework (GEF): framework for creating rich graphical editors based on existing application model Eclipse Graphical Modeling Framework (GMF): provides a generative component and runtime infrastructure for developing graphical editors based on EMF and GEF 44
Implementation with Eclipse Tools Tasks: 1. Create metamodel in EMF (abstract syntax) 2. Add constraints in OCL to the metamodel (static semantic) 3. Create GMF editor definition from metamodel (concrete syntax) 4. Generate metamodel and editor code 5. Adjust generated code 6. Run editor in Eclipse 45
Implementation with Eclipse Tools 1. Create metamodel in EMF EMF metametamodel is Ecore similar to EMOF or UML class diagram Eclipse EMF provides simple Ecore editor EMF metamodel can be imported from Rational UML model, annotated Java classes, or XMI Graphical Editor can be used from GMF or e.g. Omondo EclipseUML 46
Implementation with Eclipse Tools 2. Add constraints to metamodel No native constraint element in Ecore metamodel! In UML, annotations are used to visualize constraints EAnnotation elements can be used to add constraints to metamodel Constraints expressed in OCL Validation of constraints by external tool (e.g. Kent OCL Library) 47
Implementation with Eclipse Tools 3. Create GMF editor from metamodel Create graphic definition *.gmfgraph *.gmfmap *. gmfgen Create GMF project Create tooling definition Create generator model *. ecore Domain model ( s ) *. gmftool Configure generator parameters *. gmfgen Create mapping definition Diagram plug -ins Generate diagram plug -ins *.gmfgen *. gmfmap 48
Implementation with Eclipse Tools 3. Create GMF editor from metamodel A) Graphical definition (gmfgraph): Define Figure Gallery based on simple shapes (rectangle, rounded rectangle, polygon, ellipse, polyline, etc.) or custom shapes based on programmatic GEF figures Define graphical nodes for the specific editor Map graphical nodes to elements of the figure gallery (can be external figure gallery as well) No direct relation to metamodel Can be reused for different editors 49
Implementation with Eclipse Tools 3. Create GMF editor from metamodel B) Tooling definition (gmftool): Define tools required for editor: Menu contributions Context menu Toolbar Minimum tooling definition contains creation tools for the toolbar for each metamodel element No direct relation to metamodel Can be reused for different editors 50
Implementation with Eclipse Tools 3. Create GMF editor from metamodel C) Mapping definition (gmfmap): Connect all created models (metamodel, gmfgraph, gmftool) Map metamodel elements to corresponding graphical element and creation tool Define root diagram element Direct relation to metamodel Can use multiple models Create Generator Model from gmfmap 51
Implementation with Eclipse Tools 4. Generate metamodel and editor code Generate Java representation of metamodel from EMF generator model Generate editor code from GMF generator model resulting projects: 1. Metamodel project - contains models and metamodel code 2. Edit project - contains model editing code (properties, etc.) 3. Editor project - contains editor code (wizards, file extension, etc.) 4. Diagram project - contains GEF code for diagram editor All projects are Eclipse Plug-ins and can be launched! 52
Implementation with Eclipse Tools 5. Adjust generated code Source code of plugins is available JavaDoc-tags mark generated code parts ( @generated ) Changes of code required for special use-cases Mark manually changed code parts with @generated NOT Code generation will not override changed parts 53
Implementation with Eclipse Tools 6. Run editor in Eclipse Generated projects all Eclipse Plugins Run plugins withing runtime workbench or export as feature Plugins include: Creation wizards Menu extensions Simple model editor GMF graphical editor File extension registration 54
Agenda Goals Model-Driven Software Development Pro-active Infrastructure (PAI) Operational Aspects PAI Operational Model DSL for the Operational Model Model Transformations Implementation with Eclipse Tools Demo Conclusion References 55
Agenda Goals Model-Driven Software Development Pro-active Infrastructure (PAI) Operational Aspects PAI Operational Model DSL for the Operational Model Model Transformations Implementation with Eclipse Tools Demo Conclusion References 56
Conclusion Formal modeling is essential for managing complexity Operational aspects are too komplex NOT to be modeled Metamodeling approaches based on MOF / Ecore provide solid foundation for the creation of custom DSLs Eclipse Tools (EMF, GEF, GMF, etc.) can be good starting point for the implementation of DSLs GMF still in heavy development, major changes to be expected until version 1.0 Advanced modeling support (multi-user, rights management, change management, versioning, etc.) has to be provided by other tools or to be self-implemented For complete modeling solution for PAI Operational Model, some major effort has to be applied, but generative approach makes solution very flexible and changes can be applied easily 57
Agenda Goals Model-Driven Software Development Pro-active Infrastructure (PAI) Operational Aspects PAI Operational Model DSL for the Operational Model Model Transformations Implementation with Eclipse Tools Demo Conclusion References 58
References Modellierung operational Aspekte von Systemarchitekturen Mirko Bleyh http://www.mirkobleyh.de/diplom/diplomarbeit.pdf GMF Tutorial Part 1 + 2 http://wiki.eclipse.org/index.php/graphical_modeling_framework IBM Model Transformation Framework http://www.alphaworks.ibm.com/tech/mtf Kent OCL Library http://www.cs.kent.ac.uk/projects/ocl/ Modellgetriebene Softwareentwicklung M. Völter, T. Stahl dpunkt.verlag www.voelter.de Moderne Softwarearchitektur J. Siedersleben dpunkt.verlag 59
The End Thank you! Contact: mirko.bleyh@gmx.de 60