SBVR to OWL 2 Mappings - An Automatable and Structural-Rooted Aproach

La amplia aplicabilidad del mapeo de reglas de negocio en sentencias ontológicas ha sido recientemente reconocida. Algunas de las aplicaciones más importantes son: (1) la utilización de razonadores ontológicos para probar la consistencia de la información del dominio del negocio, (2) la generación de una ontología destinada a ser utilizada en la etapa de análisis del proceso de desarrollo de software, y (3) la posibilidad de encapsular la especificación declarativa del conocimiento del negocio en un sistema de información mediante la implementación de una ontología. El lenguaje denominado Semantics of Business Vocabulary and Business Rules (SBVR) brinda soporte a tal enfoque al proveer al experto del negocio una forma lingüistica de describir semánticamente los conceptos y especificar las reglas de negocio, en forma independiente al diseño del sistema de información. Aunque trabajos previos han presentado algunas propuestas, resta definir un enfoque exhaustivo y automatizable de tales mapeos. Este trabajo presenta un conjunto amplio y detallado de transformaciones que permiten la generación automatizable de una ontología implementada en OWL 2, partiendo de la especificación SBVR del dominio del negocio. Tales transformaciones están basadas en la especificación estructural de ambos estándars, y son descriptas mediante un caso de estudio. Se ha realizado un ejemplo real de validación, abordando la factibilidad de los mapeos mediante la evalución de la calidad de la ontología resultante.Wide applicability of mapping business rules expressions to ontology statements have already been recognized. Some of the most important applications are: (1) using of ontology reasoners to prove the consistency of business domain information, (2) generation of an ontology intended to be used in the analysis stage of a software development process, and (3) the possibility of encapsulate the declarative specication of business knowledge into information software systems by means of an implemented ontology. The Semantics of Business Vocabulary and Business Rules (SBVR) supports that approach by providing business people with a linguistic way to semantically describe business concepts and specify business rules in an independent way of any information system design. Previous work have presented some proposals but an exhaustive and automatable approach for them still is lacking. This work presents a broad and detailed set of transformations that allows the automatable generation of an OWL 2 ontology from the SBVR specications of a business domain. Such transformations are rooted on the structural specication of both standards and are depicted through a case study. A real case validation example was performed, approaching the feasibility of the mappings by the quality assessment of the developed ontology.Fil: Reynares, Emiliano. Consejo Nacional de Investigaciones Científicas y Técnicas; Argentina. Universidad Tecnologica Nacional. Facultad Regional Santa Fe. Centro de Investigacion y Desarrollo de Ingenieria en Sistemas de Informacion; ArgentinaFil: Caliusco, Maria Laura. Consejo Nacional de Investigaciones Científicas y Técnicas; Argentina. Universidad Tecnologica Nacional. Facultad Regional Santa Fe. Centro de Investigacion y Desarrollo de Ingenieria en Sistemas de Informacion; ArgentinaFil: Galli, Maria Rosa. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Santa Fe. Instituto de Desarrollo y Diseño (i); Argentin

Applying EDON Methodology and SBVR2OWL Mappings for Building an Ontology-Aware Software

In Ontology-Aware Software, ontologies are use at run time to, for example, use their content in operations of information searching or as database substitutes for information storage. In order to integrate the software development and ontology building processes, involved in building ontologyaware information system a methodology called EDONhave defined. The main disadvantage of this methodology is that the heuristic to generate an implemented ontology from the requirement elicitation is not complete enough. On the other hand, recently, the Object Management Group (OMG) has standardized a language called Semantics of Business Vocabulary and Rules (SBVR) and different approaches have been proposed to map SBVR expressions into the OWL ontology language. In this paper, we report our experience in developing an ontology-aware information system by using an adaptation of the EDON methodology including the SBVR2OWL mappings.V Workshop innovación en sistemas de softwareRed de Universidades con Carreras en Informática (RedUNCI

Checking the Compliance of Business Process in Business Process Life Cycle

International audienceBusiness process compliance has become more and more important function for business process management (BPM). One of challenges in this area is to check the business process compliance in the business process life-cycle (design-time, run-time). In this paper, we propose a description logic-based approach for business process compliance checking during two phases of the business process life-cycle. In our approach, business process and the set of regulations are represented in a machine readable form. And we use that knowledge bases to check the compliance between them

A Ontology-based Approach for Business Process Compliance Checking

International audienceThe early detection of flaws and errors has become a significant feature of a business process modeling tool. This paper proposes an ontology-based approach for business process compliance checking. The business processes and the business rules are represented in a machine understandable form, a reasoner is used to reason on this knowledge base for detecting the potential semantic error by using a set of predefined rules

Traceability of Requirements and Software Architecture for Change Management

At the present day, software systems get more and more complex. The requirements of software systems change continuously and new requirements emerge frequently. New and/or modified requirements are integrated with the existing ones, and adaptations to the architecture and source code of the system are made. The process of integration of the new/modified requirements and adaptations to the software system is called change management. The size and complexity of software systems make change management costly and time consuming. To reduce the cost of changes, it is important to apply change management as early as possible in the software development cycle. Requirements traceability is considered crucial in change management for establishing and maintaining consistency between software development artifacts. It is the ability to link requirements back to stakeholders’ rationales and forward to corresponding design artifacts, code, and test cases. When changes for the requirements of the software system are proposed, the impact of these changes on other requirements, design elements and source code should be traced in order to determine parts of the software system to be changed. Determining the impact of changes on the parts of development artifacts is called change impact analysis. Change impact analysis is applicable to many development artifacts like requirements documents, detailed design, source code and test cases. Our focus is change impact analysis in requirements and software architecture. The need for change impact analysis is observed in both requirements and software architecture. When a change is introduced to a requirement, the requirements engineer needs to find out if any other requirement related to the changed requirement is impacted. After determining the impacted requirements, the software architect needs to identify the impacted architectural elements by tracing the changed requirements to software architecture. It is hard, expensive and error prone to manually trace impacted requirements and architectural elements from the changed requirements. There are tools and approaches that automate change impact analysis like IBM Rational RequisitePro and DOORS. In most of these tools, traces are just simple relations and their semantics is not considered. Due to the lack of semantics of traces in these tools, all requirements and architectural elements directly or indirectly traced from the changed requirement are candidate impacted. The requirements engineer has to inspect all these candidate impacted requirements and architectural elements to identify changes if there are any. In this thesis we address the following problems which arise in performing change impact analysis for requirements and software architecture. Explosion of impacts in requirements after a change in requirements. In practice, requirements documents are often textual artifacts with implicit structure. Most of the relations among requirements are not given explicitly. There is a lack of precise definition of relations among requirements in most tools and approaches. Due to the lack of semantics of requirements relations, change impact analysis may produce high number of false positive and false negative impacted requirements. A requirements engineer may have to analyze all requirements in the requirements document for a single change. This may result in neglecting the actual impact of a change. Manual, expensive and error prone trace establishment. Considerable research has been devoted to relating requirements and design artifacts with source code. Less attention has been paid to relating Requirements (R) with Architecture (A) by using well-defined semantics of traces. Designing architecture based on requirements is a problem solving process that relies on human experience and creativity, and is mainly manual. The software architect may need to manually assign traces between R&A. Manual trace assignment is time-consuming, expensive and error prone. The assigned traces might be incomplete and invalid. Explosion of impacts in software architecture after a change in requirements. Due to the lack of semantics of traces between R&A, change impact analysis may produce high number of false positive and false negative impacted architectural elements. A software architect may have to analyze all architectural elements in the architecture for a single requirements change. In this thesis we propose an approach that reduces the explosion of impacts in R&A. The approach employs semantic information of traces and is supported by tools. We consider that every relation between software development artifacts or between elements in these artifacts can play the role of a trace for a certain traceability purpose like change impact analysis. We choose Model Driven Engineering (MDE) as a solution platform for our approach. MDE provides a uniform treatment of software artifacts (e.g. requirements documents, software design and test documents) as models. It also enables using different formalisms to reason about development artifacts described as models. To give an explicit structure to requirements documents and treat requirements, architecture and traces in a uniform way, we use metamodels and models with formally defined semantics. The thesis provides the following contributions: A modeling language for definition of requirements models with formal semantics. The language is defined according to the MDE principles by defining a metamodel. It is based on a survey about the most commonly found requirements types and relation types. With this language, the requirements engineer can explicitly specify the requirements and the relations among them. The semantics of these entities is given in First Order Logic (FOL) and allows two activities. First, new relations among requirements can be inferred from the initial set of relations. Second, requirements models can be automatically checked for consistency of the relations. Tool for Requirements Inferencing and Consistency Checking (TRIC) is developed to support both activities. The defined semantics is used in a technique for change impact analysis in requirements models. A change impact analysis technique for requirements using semantics of requirements relations and requirements change types. The technique aims at solving the problem of explosion of impacts in requirements when semantics of requirements relations is missing. The technique uses formal semantics of requirements relations and requirements change types. A classification of requirements changes based on the structure of a textual requirement is given and formalized. The semantics of requirements change types is based on FOL. We support three activities for impact analysis. First, the requirements engineer proposes changes according to the change classification before implementing the actual changes. Second, the requirements engineer indentifies the propagation of the changes to related requirements. The change alternatives in the propagation are determined based on the semantics of change types and requirements relations. Third, possible contradicting changes are identified. We extend TRIC with a support for these activities. The tool automatically determines the change propagation paths, checks the consistency of the changes, and suggests alternatives for implementing the change. A technique that provides trace establishment between R&A by using architecture verification and semantics of traces. It is hard, expensive and error prone to manually establish traces between R&A. We present an approach that provides trace establishment by using architecture verification together with semantics of requirements relations and traces. We use a trace metamodel with commonly used trace types. The semantics of traces is formalized in FOL. Software architectures are expressed in the Architecture Analysis and Design Language (AADL). AADL is provided with a formal semantics expressed in Maude. The Maude tool set allows simulation and verification of architectures. The first way to establish traces is to use architecture verification techniques. A given requirement is reformulated as a property in terms of the architecture. The architecture is executed and a state space is produced. This execution simulates the behavior of the system on the architectural level. The property derived from the requirement is checked by the Maude model checker. Traces are generated between the requirement and the architectural components used in the verification of the property. The second way to establish traces is to use the requirements relations together with the semantics of traces. Requirements relations are reflected in the connections among the traced architectural elements based on the semantics of traces. Therefore, new traces are inferred from existing traces by using requirements relations. We use semantics of requirements relations and traces to both generate/validate traces and generate/validate requirements relations. There is a tool support for our approach. The tool provides the following: (1) generation/validation of traces by using requirements relations and/or verification of architecture, (2) generation/validation of requirements relations by using traces. A change impact analysis technique for software architecture using architecture verification and semantics of traces between R&A. The software architect needs to identify the impacted architectural elements after requirements change. We present a change impact analysis technique for software architecture using architecture verification and semantics of traces. The technique is semi-automatic and requires participation of the software architect. Our technique has two parts. The first part is to identify the architectural elements that implement the system properties to which proposed requirements changes are introduced. By having the formal semantics of requirements relations and traces, we identify which parts of software architecture are impacted by a proposed change in requirements. We have extended TRIC for determining candidate impacted architectural elements. The second part of our technique is to propose possible changes for software architecture when the software architecture does not satisfy the new and/or changed requirements. The technique is based on architecture verification. The output of verification is a counter example if the requirements are not satisfied. The counter example is used with a classification of architectural changes in order to propose changes in the software architecture. These changes produce a new version of the architecture that possibly satisfies the new or the changed requirements

Muslim tourists' perceived value, satisfaction, religiousity and behavioural intention in patronizing Muslim friendly hotels

The increasing number of Muslim travellers has led to an increase in the demand and supply of Islamic tourism in the hospitality industry. Because of this trend, hotels have started to provide innovative services, in particular, the Muslimfriendly services to specifically cater to the needs of Muslim travellers. While the services have gained popularity, only a few empirical studies have investigated the relationship between the perceived value, satisfaction, and behavioural intentions of Muslim tourists towards Muslim-friendly hotels. Perceived value has been acknowledged as an influential measure of customer satisfaction and behavioural intention. Researchers have proposed a measure of theoretical knowledge and provided empirical evidence on the concept of perceived value, but only a few have applied this concept from the Muslim tourists’ perspective. Thus, this study aims to fill this gap by empirically investigating the mediating effect of Muslim tourists’ satisfaction in the relationship between tourist perceived value and tourist behavioural intention in patronising Muslim-friendly hotels in Malaysia. In addition, this study also examines how Islamic Religiosity moderates the relationship between tourist satisfaction and behavioural intention. By drawing upon the Theory of Reasoned Action, a conceptual framework was developed. Data was collected via a questionnaire survey distributed to 384 Muslim tourists, who experienced the services provided by eight selected Muslim-friendly hotels in Malaysia. The data collected were then analysed using Partial Least Squares-Structural Equation Modelling (PLS-SEM) via Smart PLS3 software. The findings of this study indicate that service quality, emotional, Islamic physical attributes, and Islamic nonphysical attributes are interrelated factors that collectively contribute to Muslim tourists’ satisfaction. Findings also confirm the role of satisfaction as a mediator in the relationship between (i) service quality, (ii) emotional, (iii) Islamic physical attributes, (iv) Islamic nonphysical attributes and behavioural intention. Lastly, the results of this study reveal that Islamic religiosity does not moderate the relationship between customer satisfaction and behavioural intention. Hence, this study offers conclusive insights for various stakeholders, such as academicians, practitioners, and policymakers. This study also calls for the government and other related agencies to engage in various cautionary strategies. In sum, the availability of Islamic attributes, along with conventional dimensions (service quality and emotional attributes) could increase the satisfaction of Muslim tourists during their stay at Muslim-friendly hotels

Combining SOA and BPM Technologies for Cross-System Process Automation

This paper summarizes the results of an industry case study that introduced a cross-system business process automation solution based on a combination of SOA and BPM standard technologies (i.e., BPMN, BPEL, WSDL). Besides discussing major weaknesses of the existing, custom-built, solution and comparing them against experiences with the developed prototype, the paper presents a course of action for transforming the current solution into the proposed solution. This includes a general approach, consisting of four distinct steps, as well as specific action items that are to be performed for every step. The discussion also covers language and tool support and challenges arising from the transformation