Ali Hamie

Translating the Object Constraint Language into the Java Modelling Language

The Object Constraint Language OCL is a textual specification language that could be used for constraining the modelling elements that occur in UML diagrams. Typical constraints include class invariants and preconditions and postconditions of operations. The Java Modelling Language (JML) is a behavioural interface specification language designed for specifying Java classes and interfaces. This paper defines a translation of OCL expressions and constraints into the Java Modelling Language. The objective of this translation is to be able to map UML object-oriented designs with OCL constraints to Java classes and interfaces annotated with JML specifications, and to carry out logical reasoning about such classes and interfaces using JML tools which include a run time assertion checker and an interactive prover based on PVS.

On the Relationship between the Object Constraint Language (OCL) and the Java Modeling Language (JML)

The Object Constraint Language (OCL) is a formal specification language that could be used for constraining the modelling elements that occur in UML diagrams. The Java Modeling Language (JML) is a behavioural interface specification language designed for specifying Java classes and interfaces. This paper investigates the mapping of OCL constraints to JML constraints together with its properties. In particular the paper shows how those constructs such as iterators that are not directly supported by JML are transformed to an equivalent form that can be mapped directly to JML. The paper proposes a special library for OCL types implemented in Java that facilitates the mapping. Extracts from a case study was used to illustrate the mapping

Evaluating Diagrammatic Patterns for Ontology Engineering

Diagrammatic logics have been widely studied since Shin’s seminal work on Venn diagrams in the 1990s. There have been significant theoretical advances alongside empirical work investigating their efficacy with respect to symbolic notations. However, we have little understanding about how to choose between syntactically different diagrams when formulating logical axioms. This paper sets out to provide insight into such choices. By appealing to ontology engineering, we identify commonly required semantic properties that require axiomatization. We systematically identify three different ways of axiomatizing these properties using diagrammatic patterns. One way does not use explicit quantification. The other ways both use explicit quantification but employ different diagrammatic devices to capture the required semantics. We evaluated these competing patterns by conducting an empirical study, collecting performance data. We conclude that avoiding explicit quantification, and representing the information purely diagrammatically, best supports task performance. As a result, users and designers of diagrammatic logics are guided towards avoiding explicit quantification where possible.

Contract-oriented specifications

In object classes developed using design-by-contract, contracts contain assertions that formalise pre-conditions, post-conditions and invariants. To be sure that contracts are complete, they can be derived from specifications. For classes in a data structure library, equational specifications are appropriate. However, a conventional equational specification cannot usually be mapped directly to contracts. Instead, a second, contract-oriented, equational specification can be devised, with two key properties: it can be proved that the contract-oriented specification implies the original specification; and the contract-oriented specification can be mapped systematically to contracts. These two properties combine to increase the confidence that the contracts capture the same abstraction as the equational specification.

Pattern-based mapping of OCL specifications to JML contracts

OCL is a formal notation to specify constraints on UML models that cannot otherwise be expressed using diagrammatic notations such as class diagrams. The type of constraints that can be expressed using OCL include class invariants and operation preconditions and postconditions. However, since OCL constraints cannot be directly executed and checked at runtime by an implementation, constraints violations may not be detected or noticed causing many potential development and maintenance problems. This paper describes an approach for deriving a JML specification for a java implementation (a contract) from a specification written in UML and augmented with OCL constraints. This facilitates the checking of OCL constraints at runtime by translating them to JML executable assertions. The approach is based on the concept of constraint patterns that enable the reuse of commonly occurring constraints within a given context in software modelling. Each OCL constraint pattern would be mapped to a corresponding JML pattern that can be used in the translation process. The result is a library of JML constraint patterns that provides a seamless transition from UML/OCL designs to Java implementations.

Using Patterns to Map OCL Constraints to JML Specifications

OCL is a formal notation to specify constraints on UML models that cannot otherwise be expressed using diagrammatic notations such as class diagrams. The type of constraints that can be expressed using OCL include class invariants and operation preconditions and postconditions. Constraint patterns can be used to simplify the development of consistent constraints for UML/OCL models. This paper investigates an approach based on constraint patterns to developing JML specifications for Java implementations from OCL constraints. This would enable the checking of OCL constraints at runtime since they can be translated to JML executable assertions. The approach involves mapping each OCL constraint pattern to a corresponding JML pattern. This results in a library of JML constraint patterns that provides a seamless transition from UML/OCL designs to Java implementations.

Visual logics help people: An evaluation of diagrammatic, textual and symbolic notations

Our aim is to provide empirical evidence that diagrammatic logics are more effective than symbolic and textual logics in allowing people to better understand information. Ontologies provide an important focus for such an empirical study: people need to understand the axioms of which ontologies comprise. A between-groups study compared six frequently-used axiom types using the (textual) Manchester OWL Syntax (MOS), (symbolic) description logic (DL) and concept diagrams. Concept diagrams yielded significantly better task performance than DL for all six, and MOS for four, axiom types. MOS outperformed concept diagrams for just one axiom type and DL for only three axiom types. Thus diagrams could ensure ontologies are developed more robustly.

A decision procedure for a decidable fragment of generalized constraint diagrams

Constraint diagrams were introduced by Kent, in 1997, as an alternative to the OCL for placing formal constraints on software models. Since their introduction, constraint diagrams have evolved and, after a careful analysis of their positive and negative features, generalized constraint diagrams were proposed. An important benefit of providing a formal model of a software system (diagrammatically or otherwise) is the ability to determine whether that model is consistent (i.e. satisfiable). However, determining satisfiability in an algorithmic, terminating, way is only possible in decidable logics. In this paper, we consider the so-called unitary existential fragment (UEF) of generalized constraint diagrams and, within this fragment, identify a decision procedure for the satisfiability of a particular class of diagrams. We then demonstrate how to extend the decision procedure to the UEF as a whole. This work lays the foundations for providing decision procedures for larger fragments of generalized constraint diagrams and we discuss how this might be achieved in the paper.

Visual Specification Patterns

Visual modelling notations such as constraint diagrams can be used for the behavioural specifications of software components. This includes specifying invariants on classes or types and preconditions and postconditions of operations. However, one current problem in specifying components comes from the fact that editing constraints manually is time consuming and error prone and so we may adopt a pattern-based approach to alleviate this problem. One way to simplify the definition of constraints is to identify and capture those recurring constraints in the form of visual specification patterns. Such patterns would facilitate the automatic generation of diagrammatic constraints. This paper identifies some specification patterns that frequently occur when specifying software components and provides a diagrammatic representation of these patterns. This will form the basis of a library of specification patterns that could be used in the context of tools. We also show how such patterns can be combined in order to specify more complex constraints.

The Efficacy of OWL and DL on User Understanding of Axioms and Their Entailments

OWL is recognized as the de facto standard notation for ontology engineering. The Manchester OWL Syntax (MOS) was developed as an alternative to symbolic description logic (DL) and it is believed to be more effective for users. This paper sets out to test that belief from two perspectives by evaluating how accurately and quickly people understand the informational content of axioms and derive inferences from them. By conducting a between-group empirical study, involving 60 novice participants, we found that DL is just as effective as MOS for people’s understanding of axioms. Moreover, for two types of inference problems, DL supported significantly better task performance than MOS, yet MOS never significantly outperformed DL. These surprising results suggest that the belief that MOS is more effective than DL, at least for these types of task, is unfounded. An outcome of this research is the suggestion that ontology axioms, when presented to non-experts, may be better presented in DL rather than MOS. Further empirical studies are needed to explain these unexpected results and to see whether they hold for other types of task.