Modern distributed systems contain a large number of objects, and must be capable of evolving, without shutting down the complete system, to cater for changing requirements. There is a need for distributed, automated management agents whose behavior also has to dynamically change to reflect the evolution of the system being managed. Policies are a means of specifying and influencing management behavior within a distributed system, without coding the behavior into the manager agents. Our approach is aimed at specifying implementable policies, although policies may be initially specified at the organizational level (c.f. goals) and then refined to implementable actions. We are concerned with two types of policies. Authorization policies specify what activities a manager is permitted or forbidden to do to a set of target objects and are similar to security accesscontrol policies. Obligation policies specify what activities a manager must or must not do to a set of target objects and essen...

Research issues related to requirements modeling are introduced and discussed through a review of the requirements modeling language RML, its peers and its successors from the time it was first proposed at the Sixth International Conference on Software Engineering (ICSE-6) to the present---ten ICSEs later. We note that the central theme of "Capturing More World Knowledge" in the original RML proposal is becoming increasingly important in Requirements Engineering. The paper highlights key ideas and research issues that have driven RML and its peers, evaluates them retrospectively in the context of experience and more recent developments, and points out significant remaining problems and directions for requirements modeling research. 1. Introduction "...Requirements definition is a careful assessment of the needs that a system is to fulfill. It must say why a system is needed, based on current and foreseen conditions, which may be internal operations or an external market. It must say wh...

It is not sufficient to merely check the syntax of new policies before they are deployed in a system; policies need to be analyzed for their interactions with each other and with their local environment. That is, policies need to go through a ratification process. We believe policy ratification becomes an essential part of system management as the number of policies in the system increases and as the system administration becomes more decentralized. In this paper, we focus on the basic tasks involved in policy ratification. To a large degree, these basic tasks can be performed independent of policy model and language and require little domain-specific knowledge. We present algorithms from constraint, linear, and logic programming disciplines to help perform ratification tasks. We provide an algorithm to efficiently assign priorities to the policies based on relative policy preferences indicated by policy administrators. Finally, with an example, we show how these algorithms have been integrated with our policy system to provide feedback to a policy administrator regarding potential interactions of policies with each other and with their deployment environment. 1

Nowadays, object specification technology is successfully used for modelling information systems. However, object-oriented modelling cannot cover all aspects (e.g. dynamic behaviour evolution) of such systems.

Requirements specifications are often inconsistent. Inconsistencies may arise because multiple conflicting requirements are embodied in these specifications, or because the specifications themselves are in a transient stage of evolutionary development. In this paper we argue that such inconsistencies, rather than being undesirable, are actually useful drivers for changing the requirements specifications in which they arise. We present a formal technique to reason about inconsistency handling changes. Our technique is an adaptation of logical abduction -- adapted to generate changes that address some specification inconsistencies, while leaving others. We represent our specifications in quasi-classical (QC) logic -- an adaptation of classical logic that allows continued reasoning in the presence of inconsistency. The paper develops a sound algorithm for automating our abductive reasoning technique and presents illustrative examples drawn from a library system case study. 1 Introduction...

Objects in information systems usually have a very long life-span. Therefore, it often happens that during the life of an object external requirements are changing, e.g. changes of laws. Such changes often require the object to adopt another behavior. In consequence, it is necessary to get a grasp of dynamically changing object behavior. Unfortunately, not all possible changes can in general be taken into account in advance at specification time. Hence, current object specification approaches cannot deal with this problem. Flexible extensions of object specification are needed to capture such situations. The approach we present and discuss in this paper is an important step towards a specification framework based on the concept of agents by introducing a certain form of knowledge as part of the internal state of objects. Especially, we concentrate on the specification of evolving temporal behavior. For that, we propose an extension (called Evolving Temporal Logic) of classica...

A feature is a part or aspect of a specification which a user perceives as having a self-contained functional role. In large specifications there are several problems that make the manipulation of features difficult: the part of the specification describing a feature is widely distributed over the whole specification, and features may interact in ways that are hard to predict. To overcome these problems, we aim to construct a feature-oriented specification language which allows the specifier to talk explicitly about features and their possible interactions. In a feature oriented specification language, a feature specification should be a textual unit which is easy to understand in isolation, and easy to add, remove and respecify. However, a given feature cannot be applied to any specification; it will impose certain minimal requirements of the specification which must hold there for the feature to make sense. Thus, a feature will be defined as a parameterised theory where the parameter...

We present a formal approach for handling inconsistencies in Software Cost Reduction (SCR) specifications. The approach uses an event-based logic, called the Event Calculus, to represent SCR mode transition tables. Building on this formalism, the approach provides an abductive reasoning mechanism that enables the analysis of inconsistencies between SCR mode transition tables and global requirements (invariants), and the identification of alternative changes that would resolve such inconsistencies. Changes include addition of new invariants, refinement of existing invariants, and changes on conditions of mode transitions. The methodology is widely applicable, in particular to systems embedded in complex environments whose initial conditions cannot be completely predicted. A case study of an automobile cruise control system is used to illustrate our approach. The technique described is implemented using existing tools for abductive logic programming.

Managing inconsistency in specifications covers a range of activities from consistency checking and inconsistency analysis to inconsistency handling through action. In this paper we argue that inconsistency analysis is insufficient to determine the choice of actions to take in the presence of inconsistency. Rather, we propose that some form of `hypothetical reasoning' is needed in order to determine the consequences of different actions and thereby facilitate the decision-making process. We suggest some logic-based techniques and associated heuristics for analysing the consequences of acting in the presence of inconsistency. 1. Inconsistencies in specifications Deciding what action to take in the presence of inconsistency is difficult. Most researchers agree that eradicating inconsistency in specifications is a desirable and worthy goal, but there is an emerging view that it may also be acceptable to live with inconsistency in certain circumstances or for transient periods of time [...

A feature is a part or aspect of a specification which a user perceives as having a self-contained functional role. In large specifications there are several problems that make the manipulation of features difficult: the part of the specification describing a feature is widely distributed over the whole specification, and features may interact in ways that are hard to predict. To overcome these problems, we aim to construct a feature-oriented specification language which allows the specifier to talk explicitly about features and their possible interactions. In a feature oriented specification language, a feature specification should be a textual unit which is easy to understand in isolation, and easy to add, remove and respecify. However, a given feature cannot be applied to any specification; it will impose certain minimal requirements of the specification which must hold there for the feature to make sense. Thus, a feature will be defined as a parameterised theory where th...