. This paper provides an overview of the OCML modelling language: it illustrates the underlying philosophy, describes the main modelling constructs provided, and compares it to other modelling languages. 1. INTRODUCTION OCML 1 was originally developed in the context of the VITAL project (Shadbolt et al., 1993) to provide operational modelling capabilities for the VITAL workbench (Domingue et al., 1993). Over the years the language has undergone a number of changes and improvements and in what follows we will provide an overview of the current version of the language (v5.1), illustrate its underlying philosophy and compare it to other knowledge modelling languages. 2. LANGUAGE TENETS A number of ideas/principles have shaped the development of the OCML language. These are discussed in the following sections. 2.1. Knowledge-level modelling support. The main goal of OCML is to support knowledge-level modelling (Newell, 1982; Fensel and Van Harmelen, 1994). In practice this role impl...

My PhD thesis [7] claims that the principles behind object-oriented software evolution are independent of a particular domain or phase in the software lifecycle. To validate this claim, a formalism based on graphs and graph rewriting was developed and applied to a particular aspect of software evolution, namely the problem of software upgrading and software merging. When the same piece of software is modified in parallel by different software developers, unexpected inconsistencies can arise. Formal support can be provided to detect and resolve these inconsistencies in a general way.

Abstract. The UML’s Object Constraint Language provides the modeller of object-oriented systems with ways to express the semantics of a model in a precise and declarative manner. The constraints which can be expressed in this language, all state requirements on the static aspects of the system. The Object Constraint Language currently lacks a way to express that events have happened or will happen, that signals are or will be send, or that operations are or will be called. This paper introduces an extension to OCL to solve the above problem: the so-called action clause. We describe how this extension is integrated with the UML semantics to avoid semantics overlap. It also shows that a modeler can use it to specify dynamic requirements declaratively on an abstract level, without the need to use full operational dynamic diagrams.

This document is composed of three parts. The first part describes WebOnto, a tool providing web-based visualisation, browsing and editing support for developing and maintaining ontologies and knowledge models specified in OCML. The description is user-oriented, in the sense that it is meant to provide guidance to a user, rather than to describe the tool from a scholarly perspective. The second part of the document describes OCML, an operational knowledge modelling language, which provides the underlying representation for the ontologies and knowledge bases which can be developed using WebOnto. This second part is a revised version of chapter 4 of (Motta, 1999). The third part (Appendix 1), gives more details about the interpreters and reasoning facilities provided by OCML

Object-oriented databases (OODBs) are believed to more naturally reflect the behavior and organization of complex application domains. The schema consists of a collection of classes, organized into hierarchies which nicely organize abstractions over the domain. Objects are created as instances of classes, encapsulating data and interpretation of data together. An important characteristic is the support for evolutionary programming, and so that existing programs may be extended with new classes without affecting other parts of the system.

Many conceptual modeling and system design methodologies provide tools to help system designers to model the real world. No guidelines exist, however, for determining the relationships within conceptual domains or implementations. RNA (Relationship Navigation Analysis), based on a generic relationship taxonomy, provides a systematic way of identifying useful relationships in application domains. Developers can then implement each relationship as a link. Viewing an application domain from the relationship management point of view and modeling from a philosophy of maximum access provides a unique vantage point for application design. We present RNA and its generic relationship taxonomy, describing their use for system analysis. 1. Motivation When reengineering a legacy system for the World Wide Web or developing a new Web application, how does a systems developer determine what to link? A vital aspect of hypermedia system design [8] is identifying relationships and implementing them as...

A helpful abstraction of a group of agents is a set of interacting roles, or sets of normative behaviors, that the agents can assume. An important characteristic of real-world agent systems is that the roles played by an agent may change over time. These changes can be of several different kinds. We describe an illustrative application where such role changes are important, analyze and classify the various kinds of role changes over time that may occur, and show how this analysis is useful in developing a more formal description of the application.

Unified Modeling Language (UML) defines a standard notation for object-oriented systems. Using UML enhances communication between domain experts, workflow specialists, software designers and other professionals with different backgrounds. UML can be used on a general level, which is intuitive for the users of workflow systems. In spite of this, UML symbols also have precisely defined semantics, which means that the visual workflow description can be used as a software specification. This position paper explains how to use UML for specification of workflow management systems, how to trace the description of business processes to the object-oriented software design and how to structure the project repository with UML deliverables. Introduction This paper is organized in the following way. This, the first section, explains the need for a common language among software designers and users of the workflow products. The second section shows how to represent common workflow concepts in Unif...

. This paper presents a conceptual toolbox for software specification and design that contains techniques from structured and objectoriented specification and design methods. The toolbox is called TRADE (Toolkit for Requirements and Design Engineering). The TRADE tools are used in teaching informatics students structured and object-oriented specification and design techniques, but the toolkit may be of use to practicing software engineers as well. The conceptual framework of TRADE distinguishes external system interactions from internal components. External interactions in turns are divided into external functions, behavior and communication. The paper shows that structured and OO analysis offer a small number of specification techniques for these aspects, most of which can be combined in a coherent software design specification. It is also shown that the essential difference between structured and object-oriented software design approaches lies in the separation of data storage, data ...

Recently, UML has been suggested as a standard notation for the analysis and design of object-oriented systems. UML integrates the specification of static aspects of systems with that of dynamic aspects. However, UML lacks both a methodology settling the use of its various diagrams and a formal semantics which precisely fixes the meaning of diagrams. This paper makes a contribution in both areas. We focus on two diagram types for the description of the dynamic behaviour of systems: Activity diagrams and collaboration diagrams. For the main features of both diagram types we define a semantics based on Petri nets. Furthermore, we show how to use these diagram types in a design process. For this, we introduce informal translation rules which allow for the derivation of collaboration diagrams from activity diagrams. We apply the translation rules on a small example and relate the semantics of its activity diagram to the semantics of the derived collaboration diagram.