Model-driven Integration Architecture For Compliance
D1.1Version:Date:Dissemination status:Document reference:2.02009-06-08PUD1.1Model-driven Integration Architecture forComplianceProject acronym: COMPASProject name: Compliance-driven Models, Languages, and Architectures for ServicesCall and Contract: FP7-ICT-2007-1Grant agreement no.: 215175Project Duration: 01.02.2008 – 28.02.2011 (36 months)Co-ordinator:Partners:TUV Vienna University of Technology (AT)CWI Stichting Centrum voor Wiskunde en Informatica (NL)UCBL Université Claude Bernard Lyon 1 (FR)USTUTT Universitaet Stuttgart (DE)TILBURG UNIVERSITY Stichting Katholieke Universiteit Brabant (NL)UNITN Universita degli Studi di Trento (IT)TARC-PL Telcordia Poland (PL)THALES Thales Services SAS (FR)PWC Pricewaterhousecoopers Accountants N.V. (NL)This project is supported by funding from the Information Society Technologies Programme under the 7thResearch Framework Programme of the European Union.
FP7-215175COMPASD1.1v2.0Project no. 215175COMPASCompliance-driven Models, Languages, and Architectures for ServicesSpecific Targeted Research ProjectInformation Society TechnologiesStart date of project: 2008-02-01Duration: 36 monthsD1.1 Model-driven Integration Architecture for ComplianceRevision 2.0Due date of deliverable: 2008-12-31First submission date: 2008-12-30Latest submission date: 2009-06-08Organisation name of lead partner for this deliverable:TUV Technische Universität Wien, ATContributing partner(s):CWI Stichting Centrum voor Wiskunde en Informatica, NLUSTUTT Universitaet Stuttgart, DETARC-PL Telcordia Poland, PLUNITN Universita degli Studi di Trento, ITProject funded by the European Commission within the Seventh Framework ProgrammeDissemination LevelPUPPRECOPublicRestricted to other programme participants (including the Commission Services)Restricted to a group specified by the consortium (including the Commission Services)Confidential, only for members of the consortium (including the Commission Services)File: D1.1 ce.docXPage 2 of 49
FP7-215175COMPASD1.1v2.0History chartIssueDateChanged page(s)Cause of changeImplemented 92008-12-022008-12-102008-12-12Table of contentsInitial hole documentWhole documentDocument name0.982008-12-29Table 11.002008-12-30Table 11.102009-05-08Whole documentWhole document2.02009-06-08New documentTUV reviewAddressing TUV reviewRequest for reviewAddressing reviewsAdded explanations forthe relationships ofcomponents by partnercontributionsAddressing reviewsRevisingRenamed to complywith Project QualityPlanUpdating with partnercontributionsUpdating with partnercontributionsPrepare for releasingRevise according toreviewers’ commentsApproval & ReleaseWhole documentArchitecture 08Disclaimer: The information in this document is subject to change without notice. Companyor product names mentioned in this document may be trademarks or registered trademarks oftheir respective companies.All rights reserved.The document is proprietary of the COMPAS consortium members. No copying ordistributing, in any form or by any means, is allowed without the prior written agreement ofthe owner of the property rights.This document reflects only the authors’ view. The European Community is not liable for anyuse that may be made of the information contained herein.File: D1.1 ce.docPage 3 of 49
FP7-215175COMPASD1.1v2.0Contents1. Introduction . 61.1. Purpose and scope . 61.2. Document overview . 61.3. Definitions and glossary . 61.4. Abbreviations and acronyms . 82. Compliance Framework Architecture Overview . 83. COMPAS Integration Architecture . 113.1. Model-driven Integration Architecture . 243.2. View-based Modelling Framework (VbMF) . 253.2.1. Overview of the View-based Modelling Framework . 263.2.2. View-based Modelling Framework Architecture . 273.2.3. Supporting MDSD mechanisms in VbMF . 283.3. Domain Specific Languages for Compliance Concerns . 303.3.1. What are Domain-Specific Languages? . 313.3.2. DSLs based on MDSD . 313.3.3. A DSL for Specifying Locative Compliance Concerns . 333.3.4. A Sample DSL – Quality-of-Service (QoS) DSL . 343.3.5. Tools for DSL-Development . 384. Compliance Modelling . 394.1. Compliance Views . 394.2. Control flow . 394.3. Locative . 404.4. Information . 424.5. Resource . 434.6. Temporal . 444.7. Summary . 455. Conclusion . 466. Reference documents . 466.1. Internal documents . 466.2. External documents . 47File: D1.1 ce.docPage 4 of 49
FP7-215175COMPASD1.1v2.0List of figuresFigure 1Overview of COMPAS Architecture . 9Figure 2COMPAS architecture: interaction and integration of technologies and prototypes 11Figure 3Foundation of integration architecture: a view-based, model-driven tool-chain . 25Figure 4The View-based Modelling Framework with extended facilities for modelling ofcompliance concerns . 27Figure 5Top-down and bottom-up tool-chains in View-based Modelling Framework . 28Figure 6Reverse engineering of legacy code in VbMF . 30Figure 7VbMF code generator (adapted from [HZD07]) . 30Figure 8MDSD based DSL – Relevant Concepts. 32Figure 9High- and Low-Level DSLs . 32Figure 10High-Level Model of the QoS DSL . 36Figure 11Low-Level Model of the QoS DSL . 37Figure 12UML class for ComplianceRequirements . 46List of tablesTable 1 Mapping of COMPAS components into prototypes, tools and/or technologies . 23List of listingsListing 1Definition of the DSL Model for Locative Compliance Concerns . 34Listing 2Definition of a Locative Compliance Concerns . 34Listing 3The High-Level QoS DSL for the Domain Experts . 37Listing 4The Low-Level QoS DSL for the Technical Experts . 38File: D1.1 ce.docPage 5 of 49
FP7-215175COMPASD1.1v2.0AbstractBusiness compliance today is usually implemented on a per case basis. In this deliverable, wepresent the initial architecture of a framework that aims to implement this compliance in amore generalized manner. The framework leverages the advantages of the model drivensoftware development paradigm to rapidly develop and stably evolve a business compliancesolution. We give an overview of the components that make up this framework and how theyintegrate with each other, as well as explaining how the model driven approach addressessome of the challenges experienced when developing compliance solutions.1. Introduction1.1. Purpose and scopeThe COMPAS project aims to develop a demonstrable approach to solving the problem ofbusiness compliance. For the sake of demonstration, a prototype of a business compliancesoftware framework, based on the model driven development paradigm, is to be developed.WP1 focuses on development of the core and modelling aspects of this business complianceframework, as well as ensuring that it integrates with the components from the different WPsin COMPAS project.The purpose of this deliverable is to describe the architecture of this framework and elaborateon how it shall interface with the different prototypes from other WPs (2, 3 and 5). It providesa high level overview of the components from all WPs and then provides a more detailedview of the components and explains how the components integrate with each other to realisea business compliance solution.1.2. Document overviewThe deliverable has a number of sections that are now described briefly. Section 2 gives ahigh level overview of the whole COMPAS architecture. This is followed by Section 3 thatdescribes the components in more detail and explains how they integrate with each other. InSection 3, we introduce in detail the model-driven tool-chain that comes together withconcepts of domain specific languages to serve as the basis for COMPAS model-drivenintegration architecture. Section 4 will examine a number of compliance concerns andpresent our proposed approaches to modelling these concerns. Finally, Section 5 comes tosummarise the main contributions presented in this document.1.3. Definitions and glossaryArchitectural view: a view is a representation of a whole system from the perspective of arelated set of concerns.Service Oriented Architecture (SOA): an architectural style in which software components orsoftware systems operate in a loosely-coupled environment, and are deliveredto end-users in terms of software units, namely, services. A service provides astandard interface (e.g., service interfaces described using WSDL), and utilisesmessage exchange as the only communication method.File: D1.1 ce.docPage 6 of 49
FP7-215175COMPASD1.1v2.0Separation of concerns: the process of breaking a software system into distinct pieces suchthat the overlaps between those pieces are as little as possible, in order to makeit easier to understand, to design, to develop, to maintain, etc., the system.Business compliance (or compliance for short): The goal to ensure that the systems of acompany comply with regulatory or legislative provisions, or similar businessrequirements given through outer influences. A typical example is complianceto the regulations set forth in Basel II, IFRS2, MiFID3, LSF4, Tabaksblat5, andthe Sarbanes-Oxley Act, just to name a few, which cover issues such as auditorindependence, corporate governance, and enhanced financial disclosure.Domain-Specific Languages (DSL): DSLs are small languages that are tailored for a particulardomain. Usually, DSLs are simple because they are suited for a very narrowpurpose only, and they are easy to edit and to translate. To describe a broaddomain, a broad DSL can be used. To keep the smallness and simplicity ofDSLs, multiple narrow DSLs should be used, which have to be combined todescribe a broad domain. The goal of DSLs is to improve productivity andsoftware quality. DSLs raise the level of abstraction to empower users with theability to build solutions using concepts that are similar to the domain andhis/her knowledgeModel-Driven Software Development (MDSD) or Model-Driven Development (MDD): aparadigm that advocates the concept of models, that is, models will be the mostimportant development artefacts at the centre of developers’ attention. InMDSD, domain-specific languages are often used to create models that capturedomain abstraction, express application structure or behaviour in an efficientand domain-specific way. These models are subsequently transformed intoexecutable code by a sequence of model transformations.Model and meta-model: a model is an abstract representation of a system’s structure, functionor behaviour. A meta-model defines the basic constructs that may occur in aconcrete model. Meta-models and models have a class-instance relationship:each model is an instance of a meta-model.Model transformation: transformation maps high-level models into low-level models (akamodel-to-model transformations), or maps models into source code, executablecode (aka model-to-code or code generation).Role-Based Access Control (RBAC): Access control decisions are often based on the rolesindividual users take on as part of an organization. A role describes a set oftransactions that a user or set of users can perform within the context of anorganisation. RBAC provide a means of naming and describing relationshipsbetween individuals and rights, providing a method of meeting the secureprocessing needs of many commercial and civilian government organisations.Web Service Description Language (WSDL): a standard XML-based language for describingnetwork services as a set of endpoints operating on messages containing eitherdocument-oriented or procedure-oriented information. The operations andmessages are described abstractly, and then bound to a concrete networkprotocol and message format to define an endpoint. WSDL is extensible toallow description of endpoints and their messages regardless of what messageformats or network protocols are used to communicate.File: D1.1 ce.docPage 7 of 49
FP7-215175COMPASD1.1v2.0Stakeholder: In general, stakeholder is a person or organization with a legitimate interest in agiven situation, action or enterprise. In the context of this chapter, stakeholderis a person who involved in the business process development at differentlevels of abstraction, for instance, the business experts, system analysts, ITdevelopers, and so forth.1.4. Abbreviations and acronymsBPMNBusiness Process Modelling NotationBPELBusiness Process Execution LanguageDSLDomain Specific LanguageEMFEclipse Modelling FrameworkEPCEvent-Driven Process ChainETLExtract-Transform-LoadLTLLinear Temporal LogicMDAModel-Driven ArchitectureMDSDModel-Driven Software ted ArchitectureVbMFView-based Modelling FrameworkWSDLWeb Services Description LanguageWS-BPELWeb Services Business Process Execution LanguageXPDLXML Process Definition Language2. Compliance Framework Architecture OverviewMany regulations, standards and internal policies act as sources of guidance for businesscompliance in organisations. These sources, termed compliance concerns, need to betranslated into artefacts within the organization’s information systems and/or businessprocesses.The architecture of the software framework presented in this section is designed to enable anorganisation to develop and maintain compliance framework that addresses these complianceconcerns. The architecture follows the model driven development paradigm. The resultingframework should be able to address both the design time and runtime issues of a businesscompliance infrastructure.The software framework focuses on achieving businesscompliance in a process-driven SOA.File: D1.1 ce.docPage 8 of 49
FP7-215175COMPASD1.1v2.0Figure 1 shows the overview of the components that make up this architecture.Figure 1 Overview of COMPAS ArchitectureThe overview of COMPAS architecture can be broken down into a number of sections;COMPAS design time infrastructure comprises the MDSD Software Framework,Repositories, Verification Tools, and Compliance Request Languages. The MDSDSoftware Framework that includes View-based Modelling Framework (VbMF) presented inSection 3.2, and Domain-specific Languages (DSLs) introduced in Section 3.3 aids in thedevelopment of specialised modelling languages. In our case the specialised languages wouldbe used to model compliance concerns and/or other supporting elements for the complianceframework. These DSLs are what the professionals in their respective domains would use tomodel a particular organisation’s interpretation of compliance concerns. For example, theDSL components could be used to develop a modelling language for expressing onlycompliance concerns related to security legislation. The security professionals could then usesuch a DSL to develop a particular model of security that the organization is required toimplement. VbMF provides tooling that enables modelling of these concerns in separateviews that allow the designer an abstract view of a system specific to his/her domain. In ourcase, different compliance concerns can possibly be represented in different views based onthe domain experts for the various categories of compliance concerns. Verification toolingallows static validation of the models and the compliance concerns whilst the Repositoriesprovide model repositories to store models, process fragments, and compliance requirements.Compliance Request Languages are DSLs used for discovering and choosing processfragments that meet specific compliance requirements and that can be subsequentlyaggregated into end-to-end business processes.COMPAS runtime infrastructure includes the Dashboard, and the monitors which offer theability of both online and offline monitoring of systems and compliance under execution.File: D1.1 ce.docPage 9 of 49
FP7-215175COMPASD1.1v2.0Application servers provide the platforms for deploying process engines and businessservices. Enterprise Service Bus (ESB) is the integration platform for connecting andcoordinating the interaction of applications constituting the runtime infrastructure. Theruntime infrastructu
Figure 3 Foundation of integration architecture: a view-based, model-driven tool-chain . 25 . software framework, based on the model driven development paradigm, is to be developed. WP1 focuses on development of the core and modelling aspects of this business compliance
Bruksanvisning för bilstereo . Bruksanvisning for bilstereo . Instrukcja obsługi samochodowego odtwarzacza stereo . Operating Instructions for Car Stereo . 610-104 . SV . Bruksanvisning i original
10 tips och tricks för att lyckas med ert sap-projekt 20 SAPSANYTT 2/2015 De flesta projektledare känner säkert till Cobb’s paradox. Martin Cobb verkade som CIO för sekretariatet för Treasury Board of Canada 1995 då han ställde frågan
service i Norge och Finland drivs inom ramen för ett enskilt företag (NRK. 1 och Yleisradio), fin ns det i Sverige tre: Ett för tv (Sveriges Television , SVT ), ett för radio (Sveriges Radio , SR ) och ett för utbildnings program (Sveriges Utbildningsradio, UR, vilket till följd av sin begränsade storlek inte återfinns bland de 25 största
Hotell För hotell anges de tre klasserna A/B, C och D. Det betyder att den "normala" standarden C är acceptabel men att motiven för en högre standard är starka. Ljudklass C motsvarar de tidigare normkraven för hotell, ljudklass A/B motsvarar kraven för moderna hotell med hög standard och ljudklass D kan användas vid
LÄS NOGGRANT FÖLJANDE VILLKOR FÖR APPLE DEVELOPER PROGRAM LICENCE . Apple Developer Program License Agreement Syfte Du vill använda Apple-mjukvara (enligt definitionen nedan) för att utveckla en eller flera Applikationer (enligt definitionen nedan) för Apple-märkta produkter. . Applikationer som utvecklas för iOS-produkter, Apple .
The Fast Guide to Model Driven Architecture, The Basics of Model Driven Architecture (MDA) Summary This white paper is a first in a series of papers which provide a foundational and practical guide for software developers required to work within a model driven environment as prescribed by the OMG’s Model Driven Architecture (MDA ).
och krav. Maskinerna skriver ut upp till fyra tum breda etiketter med direkt termoteknik och termotransferteknik och är lämpliga för en lång rad användningsområden på vertikala marknader. TD-seriens professionella etikettskrivare för . skrivbordet. Brothers nya avancerade 4-tums etikettskrivare för skrivbordet är effektiva och enkla att
Den kanadensiska språkvetaren Jim Cummins har visat i sin forskning från år 1979 att det kan ta 1 till 3 år för att lära sig ett vardagsspråk och mellan 5 till 7 år för att behärska ett akademiskt språk.4 Han införde två begrepp för att beskriva elevernas språkliga kompetens: BI
