The purpose of this page is to list further terms used in COMPAS, define their meaning within the COMPAS project, and thereby make the project and its results more easily accessible for the public. The terms are listed alphabetically. For each term a description is provided, and if available, also a reference to where the term comes from and examples are given. The terms listed below serve to reach a better common understanding and they undergo continuous change during the COMPAS project (see column last revision).
| Term | Description | Examples | References | Last revision
|
| Business Level Event | Looking at a SOA from the perspective of multi-layered architectures (containing business logic or domain layer and the application/service/network layer), a business level event, is one that occurs in the business logic layer of an enterprise information system and that is related to a state of interest in the business logic layer | A violation of a certain type of compliance | Byung-Kook Son, Jun-Hwan Lee, Kyung-Lang Park, Cheong-Ghil Kim, Hiecheol Kim, Shin-Dug Kim, An Efficient Method to Create Business Level Events Using Complex Event Processing Based on RFID Standards, Software Technologies for Embedded and Ubiquitous Systems, 5th IFIP WG 10.2 International Workshop, SEUS 2007, Santorini Island, Greece, May 2007; CEP, Event Processing Glossary, http://complexevents.com/?p=409 | 2009-07-20 |
| Business Property Specification Language | is a graphical language that provides people who are not expert in formal logic systems (e.g.: LTL, CTL) with an intuitive formalism to express behavioral properties. BPSL has a direct semantic interpretation into both LTL and CTL. | | Y.Liu, S.Muller, and K.Xu, "A Static Compliance-Checking Framework for Business Process Models," IBM Systems Journal, vol. 46, no. 2, 2007, pp. 335 – 361, DOI: 10.1147/sj.462.0335 | 2009-07-20 |
| Collaborative service | A service implemented through the composition of services. These composed services in turn involve any kind of service. See also business process and service composition. | | NEXOF-RA Glossary. http://www.nexof-ra.eu/?q=node/187 | 2009-07-20 |
| Component | The notion of component-based software construction refers to the use of prefabricated software artifacts in building new application functions. These artifacts are often called "business objects". | | Frank Leymann, Dieter Roller: Production Workflow – Concepts and Techniques. Prentice Hall, 2000. | 2009-07-20 |
| Computational Tree Logic (CTL) | Is logic used to formally specifying temporal properties of software or hardware designs. In branching temporal logics, each moment in time may split into various possible futures. Accordingly, the structure over which branching temporal logic formulas are interpreted can be viewed as infinite computation trees, each describing the behavior of the possible computations of a nondeterministic program. | | M. Vardi, "Branching vs. Linear Time: Final Showdown," 7th Int’l Conf. on Tools and Algorithms for the Construction and Analysis of Systems, Italy, 2001, LNCS 2031, Springer Berlin / Heidelberg, 2001, pp. 1-22. | 2009-07-20 |
| Counter Example Tracing Facility | Is a facility found in model checkers that helps the process expert to resolve non-compliance. The counterexample tracing facility identifies the fragments of the business process model that are the source of non-compliance and consequently allowing the process experts to just focus on these fragments for the non-compliance resolution. | | M. Vardi, "Branching vs. Linear Time: Final Showdown," 7th Int’l Conf. on Tools and Algorithms for the Construction and Analysis of Systems, Italy, 2001, LNCS 2031, Springer Berlin / Heidelberg, 2001, pp. 1-22. | 2009-07-20 |
| Domain-specific Language (DSL) | DSLs are small languages that are tailored to be particularly expressive in a certain problem domain. DSLs can be used for specifying or modeling concrete problems of the domain the DSL was built for. The DSL describes the domain knowledge via a graphical or textual syntax, which is tied to domain-specific modelling elements. | | | 2009-07-20 |
| Event model | An event model in COMPAS is a set of events and the description of their characteristics, structure and interrelation for compliance in the domain of service oriented architectures. The events contained in the event model represent certain changes of the status of an artefact, e.g. an activity in a process, a service or any other event-generating component in a SOA. | | | 2009-07-20 |
| Exogenous coordination | Exogenous coordination refers to the ability, in a model or language, to coordinate the behavior of black-box entities (components, services, activities, etc.) from outside of those entities and without their knowledge about each other. | | | 2009-07-20 |
| Formal process model | A formal specification of a business process. | | | 2009-07-20 |
| Formal specification | A mathematical description of software that admits formal analysis and can be used for software implementation. | | | 2009-07-20 |
| Formal verification | The act of proving or disproving the correctness of intended process behavior with respect to a certain formal specification or property using formal methods of mathematics (e.g., model checking, theorem proving). | | | 2009-07-20 |
| Goal | A goal consists of a projected state of affairs which the process subject plans or intends to achieve or bring about — a personal or organizational desired end-point in some sort of assumed development. Many people endeavor to reach goals within a finite time by setting deadlines. A goal in the context of compliance management is a high level and abstract description of the compliance requirement a system has to satisfy in order to be deemed as compliant. | | Eliyahu M. Goldratt, Jeff Cox. The Goal: A Process of Ongoing Improvement. 1986. ISBN 0-88427-061-0 | 2009-07-20 |
| High-level DSL | A high-level DSL is tailored for domain experts who know the concepts, their relations, and the rules of the problem domain very well, but mostly do not have any technical background of the environment or platform the system should be executed. A problem domain is a narrow area (or region) of interest where the high-level language is applied. The high-level language provides a high level of abstraction and close mapping to the domain concepts to allow domain experts to specify or model solutions of concrete domain problems. The modeling constructs are named equal or similar to domain terminologies. Hence, domain experts can specify or model the solution of the domain problem directly using domain concepts, rather than using concepts of a programming language. This results in a better involvement of domain experts in the development process. | | | 2009-07-20 |
| License | The license is the legal instrument used by copyright laws to describe the rights granted to software users by software author. For instance, considering the WatchMe scenario, the license contains the license clauses that must be followed by the MNVO system to ensure the copyrights of the video streaming. | | | 2009-07-20 |
| License clause | A license clause is distinct article or section in a license. | | | 2009-07-20 |
| License clause model | License clause model represents diagrammatically ODRL-S, where a license is represented as a container for the clauses and arrows represent the mapping for ODRL-S elements adopted and/or extended from the corresponding ODRL license clauses models. More details can be found in D5.2, subsection 6.3. | | | 2009-07-20 |
| Linear Temporal Logic (LTL) | Is logic used to formally specifying temporal properties of software or hardware designs. In LTL each state has one possible future and can be represented using linear state sequences, which corresponds to describing the behavior of a single execution of a system. | | M. Vardi, "Branching vs. Linear Time: Final Showdown," 7th Int’l Conf. on Tools and Algorithms for the Construction and Analysis of Systems, Italy, 2001, LNCS 2031, Springer Berlin / Heidelberg, 2001, pp. 1-22. | 2009-07-20 |
| Low-level DSL | A low-level DSL is tailored for technical experts who know the aspects of the used environment, platform, or technology very well, but mostly do not have any background knowledge of the problem domain in which the software should be used. Usually, the low-level language enriches the in the high-level DSL specified or modeled concrete domain problems with technical aspects. Only the merging of the two DSLs results in a complete modeled domain problem from which the running system can be generated. Hence, the low-level DSL provides the possibility for technical experts to specify or model the additionally needed technical details. Using low-level languages, technical experts can express the additionally needed technical aspects in a language where the terminologies and notations are close or equal to the terminology of the used environment, platform, or technology. | | | 2009-07-20 |
| Monotonicity | Means that a violation to a compliance rule is not necessarily an error. In some circumstances, it is desirable to tag certain compliance rules as monotonic and others as non-monotonic. Monotonic rules are the rules that cannot be violated from a business point of view; whilst, non-monotonic rules are open to violation to a certain extend and under specific conditions. Depending on the rigidity of the rule, the process expert determines the type of the rule. | | G.Governatori, "Representing Business Contracts in RuleML," International Journal of Cooperative Information Systems, 2005, pp.181-216. | 2009-07-20 |
| Process artefact | A process artefact may be any piece of a process, such as a variable type definition, a set of import-statements or a link to a business partner. When dealing with reusability in the area of process management also fine-granular parts need to be taken into account. In order to abstract from their meaning and usage they are referred to as artefact. | | | 2009-07-20 |
| Process instance | An instantiation of a process model, i.e., a concrete execution of a business process. | | | 2009-07-20 |
| (Business) Process model | A process model prescribes the set of actions (called "activities") that make up a process, as well as control dependencies between these activities that govern the potential execution order of the dependencies, and the data flow between activities. In COMPAS we only consider process models (actually workflow models) in BPEL. BPEL is an extensible workflow-based language (see also "Workflow") for orchestrating services to service compositions. The orchestration is recursive, so that the process exposes WSDL interfaces such as the services. Process models may be specified in graph-based and/or block-structured languages. A process model specified in a graph-based language is called a process graph. A process model may be composed of one or several process fragments. | | Frank Leymann, Dieter Roller: Production Workflow – Concepts and Techniques. Prentice Hall, 2000; Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony Storey, Donald F. Ferguson: Web Service Platform Artchitecture. Prentice Hall, 2006. | 2009-07-20 |
| Property Specification Pattern | Is a high level abstraction of frequently used temporal logic formula. Each property specification pattern has (i) a pattern; defining what must occur, and (ii) a scope; indicating when the pattern should occur. | | J.Yu, T.Manh, J.Han, and Y.Jin, "Pattern-Based Property Specification and Verification for Service Composition," Web Information Systems (WISE), 2006. | 2009-07-20 |
| Reusability | This definition of the term reusability is specific to the domain of processes and service compositions in computer science. An artefact in this domain is reusable, if any tooling or technique allows for its (re-)use in a number of scenarios under minor or slight modification efforts. | | | 2009-07-20 |
| Service | A service is an abstract entity consisting of a set of capabilities offered by one or more providers to consumers. The service is provided by means of consumer service requests. The capabilities of the service and information how to use these capabilities are described in a service description. It can be realized by living beings, information systems, machines, processes etc. | | NEXOF-RA Glossary. http://www.nexof-ra.eu/?q=node/187 | 2009-07-20 |
| Service composition | A service composition is the orchestration of several services (atomic and composite services) in order to achieve a more complex functionality. Such service composition can be recursively composed to new service compositions. | | | 2009-07-20 |
| Service coordination | Service coordination is a process of describing software systems by specifying interactions and dependencies among loosely-coupled services. | | | 2009-07-20 |
| Service license | A license L(S) for a service S consists of a finite set of license clauses, which are defining context of the license (Subject clause), its permissions (Scope of rights and Evolution clauses), and requirements (Limitation of liability, Indemnity, Warranty and Financial terms clauses). | | | 2009-07-20
|
| State-explosion Problem | In a concurrent setting, the system is typically the parallel composition of many modules. As a result, the size of the state space of the system is the product of the size of the state spaces of the participating modules. This will lead to a huge state space which is known as the state-explosion problem | | M. Vardi, "Branching vs. Linear Time: Final Showdown," 7th Int’l Conf. on Tools and Algorithms for the Construction and Analysis of Systems, Italy, 2001, LNCS 2031, Springer Berlin / Heidelberg, 2001, pp. 1-22. | 2009-07-20 |
| Sub-Process | A sub-process should be understood as a closed piece of code that can be reused within a process or across multiple processes. It may also be a long-running process, which includes interactions with other partners. However, the interaction of a sub-process with its parent process is typically limited to the initiating request message and the final reply message. A sub-process may be defined either locally within another BPEL process and reused only within that process or as a BPEL process and reused across other BPEL processes. A process that is enacted or called from another (initiating) process (or sub process), and which forms part of the overall (initiating) process. Multiple levels of sub processes are possible, so a sub-process may call several sub-processes etc. Certain degrees of autonomy of a sub-process can be differentiated. Typically, autonomy rules define the rights a parent process has for the sub-process. It spans the whole spectrum from sub-processes being absolutely autonomous to the sub-process being totally controlled by the parent process. | | BPEL-SPE whitepaper https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/5cbf3ac6-0601-0010-25ae-ccb3dba1ef47Frank Leymann, Dieter Roller: Production Workflow – Concepts and Techniques. Prentice Hall, 2000. | 2009-07-20 |
| System Level Event | Looking at a SOA from the perspective of multi-layered architectures (containing business logic or domain layer and the application/service/network layer), a system level event, is one that occurs in the application/service/network layer of an enterprise information system and that is related to the change of the system elements in these layers to a state of interest, for example the invocation of a service method, or start of a business process | | Byung-Kook Son, Jun-Hwan Lee, Kyung-Lang Park, Cheong-Ghil Kim, Hiecheol Kim, Shin-Dug Kim, An Efficient Method to Create Business Level Events Using Complex Event Processing Based on RFID Standards, Software Technologies for Embedded and Ubiquitous Systems, 5th IFIP WG 10.2 International Workshop, SEUS 2007, Santorini Island, Greece, May 2007; CEP, Event Processing Glossary, http://complexevents.com/?p=409 | 2009-07-20 |
| Web Service Flow | Web Service Flows (WS-flows) are composite Web Services implemented using a process-based approach. Similarly to the traditional workflows WS-flows definitions specify declaratively collections of tasks executed by the participants in a process. Unlike the traditional workflows, the WS-flows involve only a single type of participants - Web Services. | | D. Karastoyanova, A. Houspanossian, M. Cilia, F. Leymann, and A. Buchmann: Extending BPEL for Run Time Adaptability. In Proceedings of EDOC 2005. Enschede, The Netherlands, September 2005. | 2009-07-20 |
| Workflow | Business Processes may consist of parts that are carried out on a computer and parts that are not supported by computers. The parts that are run on a computer are called workflow. | | Frank Leymann, Dieter Roller: Production Workflow – Concepts and Techniques. Prentice Hall, 2000. | 2009-07-20 |
