ion-based Analogical Inference, in Analogical Reasoning, edited by D.H. Helman, Kluwer Academic Publishers,p. 147-170 [Grosz & Rolland 1990]: G. Grosz, C. Rolland; Using artificial intelligence techniques to formalize the information system design process; Proc. Intl. Conf. Databases and Expert Systems Applications, 374-380. [Grosz & Rolland 1991] G. Grosz, C. Rolland; Why and how should we hide conceptual models; Proc. 3rd Intl. Conf. Software Engineering and Knowledge Engineering (SEKE), Skokie, USA, 28-33 [Guindon 1990] Guindon R.: Designing the design process: exploiting opportunistic thoughts, Human-Computer Interaction Journal 5, 305-344 [Guindon & Curtis 1988] Guindon R. and Curtis B.: Control of cognitive processes during software design: what tools are needed? Proc. ACM-CHI'88, 263-269 [Hagelstein 1988] Hagelstein J.: Declarative approach to information systems requirements. Knowledge Based Systems, 1, 4, 211-220 [Hahn et al. 1991] U. Hahn, M. Jarke, T. Rose: Teamwork support ...

This paper presents an approach to representing and manipulating plans based on a model of plans as a set of constraints. The !i-n-ova? 1 (Issues -- Nodes -- Orderings/Variables/Auxiliary) model is used to characterise the plan representation used within O-Plan and to relate this work to emerging formal analyses of plans and planning. This synergy of practical and formal approaches can stretch the formal methods to cover realistic plan representations, as needed for real problem solving, and can improve the analysis that is possible for production planning systems. !I-n-ova? is intended to act as a bridge to improve dialogue between a number of communities working on formal planning theories, practical planning systems and systems engineering process management methodologies. It is intended to support new work on automatic manipulation of plans, human communication about plans, principled and reliable acquisition of plan information, and formal reasoning about plans. Motivation T...

View merging, also called view integration, is a key problem in conceptual modeling. Large models are often constructed and accessed by manipulating individual views, but it is important to be able to consolidate a set of views to gain a unified perspective, to understand interactions between views, or to perform various types of analysis. View merging is complicated by incompleteness and inconsistency: Stakeholders often have varying degrees of confidence about their statements. Their views capture different but overlapping aspects of a problem, and may have discrepancies over the terminology being used, the concepts being modeled, or how these concepts should be structured. Once views are merged, it is important to be able to trace the elements of the merged view back to their sources and to the merge assumptions related to them. In this paper, we present a framework for merging incomplete and inconsistent graph-based views. We introduce a formalism, called annotated graphs, with a built-in annotation scheme for modeling incompleteness and inconsistency. We show how structure-preserving maps can be employed to express the relationships between disparate views modeled as annotated graphs, and provide a general algorithm for merging views with arbitrary interconnections. We provide a systematic way to generate and represent the traceability information required for tracing the merged view elements back to their sources, and to the merge assumptions giving rise to the elements.

We identify and analyze basic principles which necessarily underlie software measures research. In the prevailing paradigm for the validation of software measures there is a fundamental assumption that the sets of measured documents are ordered, and that measures should report these orders. We describe mathematically the nature of such orders. Consideration of these orders suggests a hierarchy of software document measures, a methodology for developing new measures, and a general approach to the analytical evaluation of measures. We also point out the importance of units for any type of measurement and stress the perils of equating document structure complexity and psychological complexity. Keywords: software measures, abstractions of software documents, software structure, analytical evaluations of measures 1 Introduction This paper presents some underlying principles for software measures research. By "software measures" we mean measures which are obtainable directly from software d...

Multiple viewpoints are often used in Requirements Engineering to facilitate traceability to stakeholders, to structure the requirements process, and to provide richer modelling by incorporating multiple conflicting descriptions. In the latter case, the need to reason with inconsistent models introduces considerable extra complexity. This paper describes an empirical study of the utility of multiple world reasoning (using abduction) for domain modelling. In the study we used a range of different models (ranging from correct to very incorrect), different fanouts, different amounts of data available from the domain, and different modelling primitives for representing time. In the experiments there was no significant change in the expressive power of models that incorporate multiple conflicting viewpoints. Whilst this does not negate the advantages of viewpoints during requirements elicitation, it does suggest some limits to the utility of viewpoints during requirements modelling. 1. Int...

realistic plan representations as needed for real problem solving, and can improve the analysis that is possible for production planning systems. 2 Representing Plans as a Set of Constraints A plan is represented as a set of constraints which together limit the behaviour that is desired when the plan is executed. Work on O-Plan [8],[34] and other practical planners has identified different entities in the plan which are conveniently grouped into three types of constraint. The set of constraints describe the possible plan elaborations that can be reached or generated as shown in figure 2. Implied Constraints Plan Level Constraints Detailed Constraints Plan State Plan Agenda Plan Entities Plan Constraints<F NaN> \Gamma<F NaN> \Gamma\Psi<F NaN> @<F NaN> @R Space of Legitimate Plan Elaborations Figure 2: Plan Constraints Define Plan Space The three types of constraint in a plan are: 1. Implied Constraints or "Issues" 1 -- represe

Among all the phases of software development, requirements are particularly difficult to specify and analyze, since requirements for any large software system originate with many different persons. Each person's view of the software requirements may be expressed in a different notation, based on that person's knowledge, experience, and vocabulary. In order to perform a knowledge-based analysis of the requirements in combination, a single knowledge representation must be capable of capturing the information expressible in several existing requirements notations. This paper introduces the notation of conceptual graphs based on semantic networks, that provides a general representation. Four common requirements notations are shown to be expressible using conceptual graphs; with algorithms and examples provided. Specifying Multiple-Viewed Software Requirements With Conceptual Graphs Title Pages ABOUT THE AUTHOR Dr. Harry S. Delugach is an Assistant Professor in the Computer Science Depar...

The use of viewpoints has long been proposed as a technique to structure evolving requirements models. In theory, viewpoints should provide better stakeholder traceability, and the ability to discover important requirements by comparing viewpoints. However, this theory has never been tested empirically. This paper reports on an exploratory case study of a key hypothesis of the viewpoints theory, namely that by creating separate viewpoint models to represent different stakeholder contributions, and explicitly merging them, important hidden requirements can be discovered. The case study compared two modelling teams using the i ∗ notation to capture requirements for new webbased counselling services for a large charitable organisation. One team used viewpoints; the other did not. The conclusions include that viewpoint merging improves the understanding of the problem domain, but is very time consuming. The process of merging was more important than the merged product. The study also indicates a need for better model management tools, as both teams encountered difficulty in managing large, evolving models. 1.

Formal methods can be neatly woven in with less formal, but more widely-used, industrial-strength methods. We show how to integrate the Larch two-tiered specification method [GHW85a] with two used in the waterfall model of software development: Structured Analysis [Ros77] and Structure Charts [YC79]. We use Larch traits to define data elements in a data dictionary and the functionality of basic activities in Structured Analysis data-flow diagrams; Larch interfaces and traits to define the behavior of modules in Structure Charts. We also show how to integrate loosely formal specification in a prototyping model by discussing ways of refining Larch specifications as code evolves. To provide some realism to our ideas, we draw our examples from a non-trivial Larch specification of the graphical editor for the Miro visual languages [HMT + 90]. The companion technical report, CMU-CS-91-111, contains the entire specification. This research was sponsored by the Avionics Lab, Wright Research a...

The importance of formally and incrementally specifying requirements is discussed. An approach based on LOTOS (Language Of Temporal Ordering Specification) is proposed that exploits desirable characteristics of the constraint-oriented style. The nature of constraint-oriented specification is discussed at some length, and guidelines for how to use it effectively with LOTOS are presented. Small introductory examples lead to the incremental specification of a file access system using the approach in the paper. It is shown how the requirements for the file access system can be gradually formalised, leading to a complete system specification. Keywords: constraint, formal method, LOTOS (Language Of Temporal Ordering Specification), requirements, specification 1 Introduction 1.1 Requirements Specification Requirements specification is a crucial activity in system development, following on from requirements capture and analysis. This is the point at which the client's requirements ar...