Reactive Rules for Emergency Management

The goal of the following survey on Event-Condition-Action (ECA) Rules is to come to a common understanding and intuition on this topic within EMILI. Thus it does not give an academic overview on Event-Condition-Action Rules which would be valuable for computer scientists only. Instead the survey tries to introduce Event-Condition-Action Rules and their use for emergency management based on real-life examples from the use-cases identified in Deliverable 3.1. In this way we hope to address both, computer scientists and security experts, by showing how the Event-Condition-Action Rule technology can help to solve security issues in emergency management. The survey incorporates information from other work packages, particularly from Deliverable D3.1 and its Annexes, D4.1, D2.1 and D6.2 wherever possible

Challenges in Bridging Social Semantics and Formal Semantics on the Web

This paper describes several results of Wimmics, a research lab which names stands for: web-instrumented man-machine interactions, communities, and semantics. The approaches introduced here rely on graph-oriented knowledge representation, reasoning and operationalization to model and support actors, actions and interactions in web-based epistemic communities. The re-search results are applied to support and foster interactions in online communities and manage their resources

A Declarative Framework for Specifying and Enforcing Purpose-aware Policies

Purpose is crucial for privacy protection as it makes users confident that their personal data are processed as intended. Available proposals for the specification and enforcement of purpose-aware policies are unsatisfactory for their ambiguous semantics of purposes and/or lack of support to the run-time enforcement of policies. In this paper, we propose a declarative framework based on a first-order temporal logic that allows us to give a precise semantics to purpose-aware policies and to reuse algorithms for the design of a run-time monitor enforcing purpose-aware policies. We also show the complexity of the generation and use of the monitor which, to the best of our knowledge, is the first such a result in literature on purpose-aware policies.Comment: Extended version of the paper accepted at the 11th International Workshop on Security and Trust Management (STM 2015

Identifying and Modelling Complex Workflow Requirements in Web Applications

Workflow plays a major role in nowadays business and therefore its requirement elicitation must be accurate and clear for achieving the solution closest to business’s needs. Due to Web applications popularity, the Web is becoming the standard platform for implementing business workflows. In this context, Web applications and their workflows must be adapted to market demands in such a way that time and effort are minimize. As they get more popular, they must give support to different functional requirements but also they contain tangled and scattered behaviour. In this work we present a model-driven approach for modelling workflows using a Domain Specific Language for Web application requirement called WebSpec. We present an extension to WebSpec based on Pattern Specifications for modelling crosscutting workflow requirements identifying tangled and scattered behaviour and reducing inconsistencies early in the cycle

An LTL Semantics of Business Workflows with Recovery

We describe a business workflow case study with abnormal behavior management (i.e. recovery) and demonstrate how temporal logics and model checking can provide a methodology to iteratively revise the design and obtain a correct-by construction system. To do so we define a formal semantics by giving a compilation of generic workflow patterns into LTL and we use the bound model checker Zot to prove specific properties and requirements validity. The working assumption is that such a lightweight approach would easily fit into processes that are already in place without the need for a radical change of procedures, tools and people's attitudes. The complexity of formalisms and invasiveness of methods have been demonstrated to be one of the major drawback and obstacle for deployment of formal engineering techniques into mundane projects

Formalizing the software development process

Object-oriented software development process, such as the Unified Process [Jacobson 99], Catalysis [D´Souza 98] and Fusion [Coleman 94] among others, is a set of activities needed to transform user’s requirements into a software system. A software development process typically consists of a set of software development artifacts together with a graph of tasks and activities. Software artifacts are the products resulting from software development, for example, a use case model, a class model or source code. Tasks are small behavioral units that usually results in a software artifact. Examples of tasks are construction of a use case model, construction of a class model and writing code. Activities (or workflows) are units that are larger than a task. Activities generally include several tasks and software artifacts. Examples of activities are requirements, analysis, design and implementation.\nModern software development processes are iterative and incremental, they repeat over a series of iterations making up the life cycle of a system. Each iteration takes place over time and it consists of one pass through the requirements, analysis, design, implementation and test activities, building a number of different artifacts. All these artifacts are not independent. They are related to each other, they are semantically overlapping and together represent the system as a whole. Elements in one artifact have trace dependencies to other artifacts.\nFor instance, a use case (in the use-case model) can be traced to a collaboration (in the design model) representing its realization.Eje: Ingeniería del Softwar

Formalizing the software development process

Object-oriented software development process, such as the Unified Process [Jacobson 99], Catalysis [D´Souza 98] and Fusion [Coleman 94] among others, is a set of activities needed to transform user’s requirements into a software system. A software development process typically consists of a set of software development artifacts together with a graph of tasks and activities. Software artifacts are the products resulting from software development, for example, a use case model, a class model or source code. Tasks are small behavioral units that usually results in a software artifact. Examples of tasks are construction of a use case model, construction of a class model and writing code. Activities (or workflows) are units that are larger than a task. Activities generally include several tasks and software artifacts. Examples of activities are requirements, analysis, design and implementation. Modern software development processes are iterative and incremental, they repeat over a series of iterations making up the life cycle of a system. Each iteration takes place over time and it consists of one pass through the requirements, analysis, design, implementation and test activities, building a number of different artifacts. All these artifacts are not independent. They are related to each other, they are semantically overlapping and together represent the system as a whole. Elements in one artifact have trace dependencies to other artifacts. For instance, a use case (in the use-case model) can be traced to a collaboration (in the design model) representing its realization.Eje: Ingeniería del SoftwareRed de Universidades con Carreras en Informática (RedUNCI

Creating a Discipline-specific Commons for Infectious Disease Epidemiology

Objective: To create a commons for infectious disease (ID) epidemiology in which epidemiologists, public health officers, data producers, and software developers can not only share data and software, but receive assistance in improving their interoperability. Materials and Methods: We represented 586 datasets, 54 software, and 24 data formats in OWL 2 and then used logical queries to infer potentially interoperable combinations of software and datasets, as well as statistics about the FAIRness of the collection. We represented the objects in DATS 2.2 and a software metadata schema of our own design. We used these representations as the basis for the Content, Search, FAIR-o-meter, and Workflow pages that constitute the MIDAS Digital Commons. Results: Interoperability was limited by lack of standardization of input and output formats of software. When formats existed, they were human-readable specifications (22/24; 92%); only 3 formats (13%) had machine-readable specifications. Nevertheless, logical search of a triple store based on named data formats was able to identify scores of potentially interoperable combinations of software and datasets. Discussion: We improved the findability and availability of a sample of software and datasets and developed metrics for assessing interoperability. The barriers to interoperability included poor documentation of software input/output formats and little attention to standardization of most types of data in this field. Conclusion: Centralizing and formalizing the representation of digital objects within a commons promotes FAIRness, enables its measurement over time and the identification of potentially interoperable combinations of data and software.Comment: 12 pages, 6 figure

Change Support in Process-Aware Information Systems - A Pattern-Based Analysis

In today's dynamic business world the economic success of an enterprise increasingly depends on its ability to react to changes in its environment in a quick and flexible way. Process-aware information systems (PAIS) offer promising perspectives in this respect and are increasingly employed for operationally supporting business processes. To provide effective business process support, flexible PAIS are needed which do not freeze existing business processes, but allow for loosely specified processes, which can be detailed during run-time. In addition, PAIS should enable authorized users to flexibly deviate from the predefined processes if required (e.g., by allowing them to dynamically add, delete, or move process activities) and to evolve business processes over time. At the same time PAIS must ensure consistency and robustness. The emergence of different process support paradigms and the lack of methods for comparing existing change approaches have made it difficult for PAIS engineers to choose the adequate technology. In this paper we suggest a set of changes patterns and change support features to foster the systematic comparison of existing process management technology with respect to process change support. Based on these change patterns and features, we provide a detailed analysis and evaluation of selected systems from both academia and industry. The identified change patterns and change support features facilitate the comparison of change support frameworks, and consequently will support PAIS engineers in selecting the right technology for realizing flexible PAIS. In addition, this work can be used as a reference for implementing more flexible PAIS