The purpose of this page is to list key components, define their meaning within the COMPAS project, and thereby make the project and its results more easily accessible for the public. The components are listed alphabetically. For components term a description is provided, and if available, also a reference to where the component comes from and a rationale is given.
| Component | Description | Reference | Rationale |
| Analysis / Business Intelligence | The Business intelligence (BI) component is in charge of analyzing the data in the data warehouse and of generating compliance reports. | | |
| Annotation Editor | The annotation editor is a text-based editor that allows to annotate artefact with other artefact. In the case of COMPAS we foresee the annotation of processes with both textual annotations and with process fragment, as well as the annotation of process fragments with textual annotations. | | The annotation of artefact allow to state constraints, metadata or any other meaningful description in various languages. |
| Application Server | The application server is the runtime environment for components such as the process engine and the services. It is often also referred to as container. | | |
| Code Generator | The Code Generator takes as inputs the modelling artefacts validated via the Model Validator, and a number of transformation templates used to produce. Then, it might perform model validations against required constraints (if any). Finally, schematic code and configurations are generated. The generated schematic code might be augmented with individual code specialized for specific business logics, particular platform features, etc. | H. Tran, U. Zdun and S. Dustdar.: View-based and Model-driven Approach for Reducing the Development Complexity in Process-Driven SOA. In Internaltional Working Conference on Business Process and Services Computing (BPSC'07), volume 116 of Lecture Notes in Informatics, pages 105-124, 2007 | |
| Complex Event Processing | “The Complex event processing (CEP) processes and analysis multiple events from distributed sources, with the objective of extracting useful information from them.” | M. Mendes, P. Bizarro, P. Marques. A framework for performance evaluation of complex event processing systems. Proceedings of the second international conference on Distributed event-based system. Distributed event-based systems; Vol. 33. P, 313-316, 2008. | |
| Compliance Governance Dashboard | The Dashboards are a user friendly graphical web based visualization of compliance information, particularly compliance violations of business process. | | |
| Compliance Language Request Tools | Is an integrated set of graphical and user-friendly tools to be used by the compliance expert. The main purpose of this component is twofold: First, the formal specification of compliance requirements at various levels of abstractions, where linear temporal logic (LTL) is its core. Second, quering the process (-fragments) repository to return the set of business process fragments that can be composed as end-to-end business process. The end-to-end business process can then be checked for compliance against the set of applicable compliance rules formally specified as LTL formulas. | | |
| Compliance Request Language | Is one of the sub-components of the ‘Compliance Language Request Tools’ component, where compliance requirements can be formally specified as a combination of logical rules in a manner that naturally expresses compliance requirements. | | |
| Compliance Requirement Repository | Stores and organizes compliance requirements at various abstractions levels (in terms of goals, policies and rules) and allows the reusability of the compliance constraints. | | |
| Converters | Three converters, namely, BPMN2Reo, UML2Reo and BPEL2Reo, are Eclipse plug-ins used to convert business process models to Reo circuits, and subsequently, to extended constraint automata, for their formal analysis and compliance verification. | F. Arbab, N. Kokash and M. Sun: Towards Using Reo for Compliance-aware Business Process Modelling. In: Proceedings of the International Symposium on Leveraging Applications of Formal Methods, Verification and Validation (ISOLA'08), vol. 17 of CCIS, Springer, 2008, pp. 108-123. S. Tasharofi, M. Vakilian, R. Z. Moghaddam, M. Sirjani: Modeling Web Service Interactions Using the Coordination Language Reo. In: Proceedings of the International Workshop on Web Services and Formal Methods, vol. 4937 of LNCS, Springer, 2008, pp. 108-123. F. Arbab and M. Sun: Synthesis of Connectors from Scenario-based Interac-tion Specifications. In: Proceedings of the International Symposium on Component Based Software Engineering (CBSE'08), 2008. | |
| Data Warehouse | A Data warehouse is an integrated, non-volatile, historical, subject-oriented data collection, aimed at supporting decision-making processes. Particularly, in COMPAS the DW stores compliance and process related data. | | |
| DSL Editor | System requirements and compliance concerns are represented in terms of Domain-Specific Languages (DSLs). DSLs describe knowledge via a graphical or textual syntax. Therefore, DSL editors are necessary for, and often used by stakeholders to manipulate the requirements | | |
| DSL Transformation | DSL transformations take as inputs the DSLs defined by using DSL editors, and then, interpret and transform them into modelling artefacts such as models, model instances and/or relevant constraints (if any) | | |
| ESB | The Enterprise Service Bus (ESB) is a unified communication channel between the components. Besides that the ESB provides a publish/subscribe mechanism for events that are published via this channel. In COMPAS the ESB is employed for publish subscribe mechanism for events, without implementing additional functionality. | | The concept of an ESB allows to abstract from the transport protocols and the physical connections that are used. |
| ETL | The ETL (extract, transform and load) processes are responsible for the extraction of the data from the Event log (possibly from Audit trail), transforming them according to the DW data model. | | |
| Event Log | An Event log can be seen as a set of past events typically ordered chronologically by the timestamps. Depending on the implementation the event log normally provides an interface to retrieve a certain sub-set of those events that occurred within a given interval. In the architecture of COMPAS the events are emitted from any component in form of messages, which can be delivered by the ESB that again provides publish/subscribe functionality for any component that is interested in a certain type or source of event. | | |
| Log Mining | Log mining refers to the activity of extracting implicit knowledge from log repository. For instance, the actual business protocol of the process can be retrieved, allowing a better understanding of service and clients behavior. In the architecture of COMPAS, knowledge from log mining is reported through the monitoring dashboard. | | |
| Process Engine | The process engine is the compoment that executes processes by navigating through the steps defined in the process model, based on the current parameters of the running process instance. A process engine describes the current status of the execution of processes by generating and emitting execution events. During execution of a business process instance the engine stores additional execution data in the audit trail e.g., incoming purchase order, and emits events to the ESB, which is used for reliable messaging and Publish-Subscribe mechanism for event messages. | | The concept of a process engine was created out of the advancement in software-engineering to separate the control logic from the application logic. |
| Process (-fragment) Repository | A repository is a kind of database that provides for querying, storage, versioning and retrieval functionality, tailored to certain kinds of models. In our domain such models are process models in the Language BPEL and the process fragments contained therein, as well as their annotations and related metadata. | | For many applications the simple storage and retrieval mechanisms that simple databases typically provide is not sufficient. Especially in modelling and development version control is of fundamental importance. |
| Process Verification Tools | Process Verification tools include a Reo animation plug-in and a Vereofy model checker. Reo animation plug-in is a tool that generates flash animated simulations of formal business process models. The plug-in depicts the process that was previously shown in the Reo editor in the animation view. The parts of the process highlighted red represent synchronous data flow. Tokens move along these synchronous regions. On the left side there is a list of possible animations for this connector and the attached writers and readers. Reo validation plug-in is a tool that performs model checking over coordination models represented as constraint automata. This model checker uses a symbolic model and LTL and CTL-like logics as property specification formats. | S. Kluppelholz, C. Baier: Symbolic model checking for channel-based component connectors, Electronic Notes in Theoretical Computer Science, 2007, 175 (2): 19-37. http://www.vereofy.de/ | |
| Reo Editor | The Reo editor is an Eclipse plug-in that enables business process modelling by simple drawing operations and serves as a bridge to a number of other tools that can be either invoked from the context menus or directly interact with it. Formal business process models are stored using an XML format and can be further verified and transformed to service compositions by wiring appropriate web services. | F. Arbab: Reo: A channel-based coordination model for component composition. Mathematical Structures in Computer Science, 2004, 14(3): 329-366. Arbab, F., Koehler, C., Maraikar, Z., Moon, Y.J., Proenca, J.: Modeling, testing and executing Reo connectors with the Eclipse coordination tools. In: Proceedings of the International Workshop on Formal Aspects in Component Software, Elsevier (2008). http://reo.project.cwi.nl/ | |
| View-based Modelling Framework | View-based Modelling Framework introduced in Section 2 which is developed by WP1 will act as a modelling foundation for representing different process concerns by exploiting the concept of architectural views. Process concerns, such as the control-flow, service invocations, data handling, etc., are modelling artefacts. These artefacts might be bound to some modelling constraints, or be associated with meta-data of some compliance concerns | H. Tran, U. Zdun and S. Dustdar.: View-based and Model-driven Approach for Reducing the Development Complexity in Process-Driven SOA. In Internaltional Working Conference on Business Process and Services Computing (BPSC'07), volume 116 of Lecture Notes in Informatics, pages 105-124, 2007. | |
