\documentstyle[fullpage]{article} % macros \newtheorem{definition}{Definition}[section] \newtheorem{theorem}{Proposition}[section] % mts macros \newtheorem{defn}{Definition}[section] \newtheorem{example}{Example}[section] %\newcommand{\nexists}{\not\negthinspace\exists} \newcommand{\myand}{\;\land\;} \newcommand{\And}{\;\land\;} \newcommand{\Or}{\;\lor\;} \newcommand{\Then}{\;\Longrightarrow\;} \newcommand{\iffi}{\;\Longleftrightarrow\;} \newcommand{\then}{\;\Longrightarrow\;} \newcommand{\In}{\;in\;} \newcommand{\Isa}{\;isA\;} \newcommand{\isA}{\;isA\;} \newcommand{\maps}{\;\longrightarrow\;} \newcommand{\xor}{\,\otimes\,} \newcommand{\comment}[1]{} \newcommand{\union}{\;\cup\;} \newcommand{\mytheta}{\;\theta\;} \newcommand{\myxi}{\;\xi\;} \renewcommand{\descriptionlabel}{\null} \newcommand{\qt}[1]{``{#1}''} \newcommand{\tb}{\hspace*{0.25in}} \newcommand{\nonterm}[1]{$<\!{\tt {#1}}>\!$} \newcommand{\nontermmath}[1]{<\!{\tt #1}>\!} \newcommand{\nt}[1]{$<\!{\tt {#1}}>\!$} \newcommand{\ntm}[1]{<\!{\tt #1}>\!} \newcommand{\term}[1]{\bf {#1}} \newcommand{\sterm}[1]{``{\bf {#1}}''} \newcommand{\believed}{\;believed} \newcommand{\at}{\;at\;} \newcommand{\equals}{\;equals\;} \newcommand{\during}{\;during\;} \newcommand{\startsbefore}{\;startsbefore\;} \newcommand{\Tendsbefore}{\;endsbefore\;} \newcommand{\rightbefore}{\;rightbefore\;} \newcommand{\before}{\;before\;} \newcommand{\costarts}{\;costarts\;} \newcommand{\coends}{\;coends\;} \newcommand{\overlaps}{\;overlaps\;} \newcommand{\overlappedby}{\;overlapped\-by\;} \newcommand{\Over}{\;over\;} \newcommand{\startsafter}{\;startsafter\;} \newcommand{\Tendsafter}{\;endsafter\;} \newcommand{\rightafter}{\;rightafter\;} \newcommand{\after}{\;after\;} \newcommand{\startsduring}{\;startsduring\;} \newcommand{\Tendsduring}{\;endsduring\;} \newcommand{\meets}{\;meets\;} \newcommand{\sort}[1]{<\!{\bf {#1}}\!>} \newcommand{\sig}[1]{\sigma({\tt {#1}})} \newcommand{\inst}{\;in\;} \newcommand{\lqq}{\mathopen{\raisebox{-.5ex}{${}^{{}^\lceil}$}\mskip-2.5mu}} \newcommand{\rqq}{\mathclose{\raisebox{-.5ex}{${}^{{}^\rceil}$}}} \newcommand{\qq}[1]{\lqq{#1}\rqq} % qq for "quine's quotes \begin{document} \bibliographystyle{acm} \flushbottom \begin{titlepage} \pagestyle{empty,nopagenumber} \vspace*{1cm} \begin{center} {\LARGE Telos: Representing Knowledge About Information Systems} \end{center} \begin{center} {\large John Mylopoulos, Alex Borgida,\\ Matthias Jarke and Manolis Koubarakis\\ \ \\ Department of Computer Science\\ University of Toronto} \end{center} We describe {\em Telos}, a language intended to support the development of information systems. The design principles for the language are based on the premise that information system development is {\em knowledge-intensive} and that {\em the primary responsibility of any language intended for the task is to be able to formally represent the relevant knowledge}. Accordingly, the proposed language is founded on concepts from knowledge representation. Indeed, the language is appropriate for representing knowledge about a variety of worlds related to an information system, such as the subject world (application domain), usage world (user models, environments), system world (software requirements, design), and development world (teams, methodologies). The paper introduces the features of the language through examples, focusing on those provided for describing meta-concepts that can then be used to describe knowledge relevant to a particular information system. Telos' features include: an object-centered framework which supports aggregation, generalization and classification; a novel treatment of attributes; an explicit representation of time; and facilities for specifying integrity constraints and deductive rules. Actual applications of the language are reviewed through further examples and a formalization of the language is sketched. \end{titlepage} \section{Introduction} Language facilities have been a key vehicle for advances in software productivity since the introduction of assembler in the early '50s, the first high level programming languages in the mid-50s, and the languages supporting encapsulation/modularization in the 70's. But programming accounts for only a small fraction of the total effort and cost of producing a software system. This paper describes a language that is intended to support software engineers in the development of information systems throughout the software lifecycle. This language is {\em not} a programming language. Following the example of a number of other software engineering projects, our work is based on the premise that information system development is {\em knowledge-intensive} and that {\em the primary responsibility of any language intended to support this task is to be able to formally represent the relevant knowledge.}\footnote{ See \cite{Rich-Waters86} for a survey of knowledge-based software engineering projects.} Accordingly, the proposed language is founded on concepts from knowledge representation \cite{Brachman-Levesque85}. Indeed, the language is viewed as a knowledge representation language appropriate for representing knowledge about an information system. This viewpoint leads to an eclectic approach on what mathematical concepts are relevant to software development and a rationalization of why some notations are more significant than others. How is a knowledge representation language different from other types of languages, such as programming or design languages, formal languages or natural languages? According to \cite{Brachman-Levesque85} (pages xiv--xv): \begin{quotation} In order to have an explicit knowledge base, a system must rely on some well-specified language for encoding its beliefs. That role is played by a {\em knowledge representation language}. Beyond that, in just about all imaginable cases of interest, a system will be concerned with more than just the literal set of sentences (or frames, or production rules, or whatever) representing what it knows. A representation system must also provide access to facts {\em implicit} in the knowledge base. In other words, a representation component must perform {\em automatic inferences} for its user. \end{quotation} The ingredients then of a knowledge representation language include {\em a (formal) notation}, and {\em a deductive mechanism for drawing inferences} from a body of statements (the knowledge base) represented in that notation\footnote{ There is a tension between the increased ``expressive power'' of a notation -- the ability to express certain facts and make certain kinds of deductions -- and the complexity of the computations involved.}. In addition, there is a need to assign some sort of ``meaning'' to statements -- {\em the semantics of the notation}; this meaning must be respected by the deductive process. Finally, to be effective in large projects, a knowledge representation language must offer {\em facilities to structure and organize the knowledge base}. The language presented in this paper is called {\em Telos}\footnote{From the Greek word $\tau\acute{\epsilon}\lambda o\varsigma$ which means {\em end}; the object aimed at in an effort; purpose.}. Like any useful language, Telos has been shaped by its subject matter. But what knowledge needs to be represented about an information system? To begin with, knowledge about the environment within which the system will function and how the system is expected to interact with that environment. Second, the kind of information the system will be expected to store and the meaning of that information with respect to its intended subject matter. Third, knowledge about the design and implementation of the information system, which can be used during initial system development as well as during system maintenance. Fourth, knowledge about design decisions that led to the particular design/implementation, along with appropriate justifications that relate these decisions to performance or other non-functional requirements. Finally, information on the development process itself that led to the system, including the methodology used, the team of developers involved, different system versions and the like. Our work is based on the premise that all this, and other, knowledge about an information system is useful during its initial development, subsequent deployment and use, maintenance and reuse. This, rather ambitious, viewpoint is grounded in our own experiences within the ESPRIT project DAIDA which is concerned with the construction of a complete information system development environment \cite{Jarke-Mylopoulos-Schmidt-Vassiliou90}. To deal with these ideas, and to meet some of the goals of a good KR language, Telos provides a number of novel facilities: representing and reasoning about (possibly incomplete) temporal knowledge; particularly general forms of conceptual structuring mechanisms such as {\em generalization} and {\em classification}; supporting linguistic extensions through the definition of meta-attributes, in order to cope with the multitude of subject matters. Also, Telos adapts concepts from deductive databases \cite{Gallaire-Nicolas89} for query processing and integrity enforcement. In keeping with general principles of good language design, attempts were also made to maintain {\em uniformity} and {\em simplicity}. Telos has evolved from RML (a requirements modeling language developed in a doctoral dissertation by Greenspan \cite{Greenspan84}), and later CML (described and formalized in \cite{Stanley86}). The major difference between RML and CML is that the latter adopts a more sophisticated data structure for representing knowledge, and supports the representation of complex temporal knowledge and the definition of meta-concepts. Telos, on the other hand, is a ``cleaned-up'' version of CML, both from a language definition and an implementation perspective, which has been implemented and tested with a variety of knowledge representation tasks related to information system development. It has been used both in the LOKI and DAIDA projects and the section on applications of the languages is based on those experiences. The paper is organized as follows. Section 2 presents and motivates the basic features of the language. In section 3, the nature and applications of metaclasses is investigated through examples. Section 4 surveys some of the applications that have been considered in the context of information system development. The formalization of Telos is reviewed in section 5, while section 6 discusses related work. Finally, section 7 summarizes the contributions of the language and suggests directions for further research. \section{Features of Telos} Telos provides facilities for constructing, querying and updating structured knowledge bases (KBs). The operations {\tt TELL}, {\tt UNTELL}, and {\tt RETELL} are offered to extend or modify a KB while the operations {\tt RETRIEVE} and {\tt ASK} can be used to access it. This section introduces Telos and illustrates its use. \subsection{Structured Knowledge Bases} A Telos knowledge base consists of structured objects built out of two kinds of primitive units: {\em individuals} and {\em attributes}. Individuals are intended to represent entities (concrete ones such as {\tt John}, or abstract ones such as {\tt Person}), while attributes represent binary relationships between entities or other relationships. An important and distinctive feature of Telos is that individuals and attributes are treated uniformly by the mechanisms for structuring a KB; they are collectively referred to by the term {\em ``proposition''}. Every attribute {\tt p} consists of a {\em source}, a {\em label} and a {\em destination}, which can be retrieved through the functions {\tt from(p), label(p)} and {\tt to(p)}. An attribute proposition will be represented for the moment by a 3-tuple, e.g., $\tt [Martin, age, 35]$. Propositions (individual or attribute) are organized along three dimensions, referred to in the literature as the {\em aggregation}, {\em classification} and {\em generalization} dimensions \cite{Hull-King87}. {\em Structured/aggregate objects} consist of collections of attributes that have a common proposition as source. For example, the individual {\tt Martin} may aggregate the cluster of propositions \begin{quote}\begin{verbatim} {Martin, [Martin, age, 35], [Martin, homeAddr, `21 Elm Avenue'], [Martin, workAddr, `10 King's College Road']} \end{verbatim}\end{quote} This indicates, among others, that {\tt Martin} has two (momentarily unrelated) attributes with labels {\tt homeAddr} and {\tt workAddr}, and values {\tt `21 Elm Avenue'} and {\tt `10 King's College Road'} respectively. Attributes may also represent abstract relationships such as {\tt [Person, address, GeographicLocation]}, intended to represent the concept of address relationships between persons and geographic locations. The classification dimension calls for each proposition to be {\em an instance} of one or more generic propositions or {\em classes}. Classes are themselves propositions, and therefore instances of other, more abstract classes. In this way both {\tt Person} and {\tt [Person, address, GeographicLocation]} are classes, with individual instances which are particular individuals and relationships respectively (e.g., {\tt Martin} and {\tt [Martin, homeAddr, `21 Elm Avenue']}. Generally, propositions are classified into {\em tokens} -- propositions having no instances and intended to represent concrete entities in the domain of discourse, {\em simple classes} -- propositions having only tokens as instances, {\em metaclasses} -- having only simple classes as instances, {\em metametaclasses}, and so on. This classification defines an unbounded linear hierarchy of planes of ever more abstract propositions. %Do we really need these in this paper? There are also $\omega$-classes with instances along more than one such plane. For example, the class {\tt Proposition} has all propositions as instances while {\tt Class} has all generic propositions as instances. Figure ~\ref{fig:semantic-net} shows the structure of the classification dimension, with sample propositions at various levels. \begin{figure} \vspace{6in} \caption{A simple semantic net} \label{fig:semantic-net} \end{figure} Instantiation is treated as a form of weak typing mechanism: the classes of which a structured object is an instance determine the kinds of attributes it can have and the properties it must satisfy. For example, by virtue of being an instance of {\tt Person}, {\tt Martin} can have attributes that are instances of {\tt [Person, address, GeographicLocation]}. Such attributes can have arbitrary labels, such as {\tt homeAddr} and {\tt workAddr}, but their values must be instances of {\tt GeographicLocation}. Classes can be specialized along {\em generalization} or {\em ISA hierarchies} For example, {\tt Person} may have subclasses such as {\tt Professor}, {\tt Student}, and {\tt TeachingAssistant}. The classes may form a partial order, rather than a tree. Note that IsA hierarchies are orthogonal to the classification dimension: all these classes could be instances of {\tt PersonClass}. As discussed later, non-token attributes of a class are inherited by more specialized ones, and inheritance is strict rather than default. \subsubsection{Interacting with a Knowledge Base: An Example} Consider the problem of developing an Information System to support organizing international scientific conferences. As part of the requirements model, the designer needs to describe the entities about which information will be maintained, such as papers, authors, conferences and the like. The following {\tt TELL} operation introduces an object to model a paper submitted to, say, an IFIP World Congress \cite{Olle-Sol-VerjinStuart82}: %%%%%%% new page \newpage \begin{quote}\begin{verbatim} TELL TOKEN martian IN Paper WITH author firstAuthor: Stanley; : LaSalle; : Wong title :`The MARTIAN system' END \end{verbatim}\end{quote} This operation defines a token with external identifier {\tt paper} and several associated attributes\footnote{Each Telos proposition has a unique internal identifier and zero or more external identifiers that can be used in Telos expressions to refer to that proposition.}. The {\tt IN} clause specifies the classes of which {\tt martian} is an instance, while the {\tt WITH} clause introduces {\tt martian}'s attributes. For example, the first attribute has label {\tt firstAuthor} and is an instance of an attribute class which has source {\tt Paper} and label {\tt author} (the latter is denoted by the {\em attribute category} {\tt author}). The second attribute has no external label and it is an instance of the same attribute class; this attribute is going to acquire a system-generated label. Continuing with the requirements model, we can use {\tt TELL} to define generic concepts which determine the database schema. Thus, the class {\tt Paper} (which is an instance of the built-in class {\tt SimpleClass}) has associated a number of attribute classes: \begin{quote}\begin{verbatim} TELL CLASS Paper IN SimpleClass WITH attribute author: Person; referee: Person; title: String; pages: 1..100 END \end{verbatim}\end{quote} As indicated earlier, a class definition prescribes the attributes that can be associated with its instances: {\tt martian} can have {\tt author, referee, title} and {\tt page} attributes {\em because} it is an instance of some class (i.e., {\tt Paper}) that has attribute classes using these labels. Moreover, {\tt [martian, firstAuthor, Stanley]} is an instance of {\tt [Paper, author, Person]} in exactly the same sense that {\tt martian} is an instance of {\tt Paper}. Once {\tt Paper} has been defined, one can introduce specializations, such as {\tt InvitedPaper} using the {\tt ISA} clause of class definitions: %%%%%%%%new page \newpage \begin{quote}\begin{verbatim} TELL CLASS AcceptedPaper IN SimpleClass ISA Paper WITH attribute pages: 1..15 session: ConfProgrammeSession END \end{verbatim}\end{quote} {\tt AcceptedPaper} inherits all attributes from {\tt Paper} and adds a {\tt session} attribute, to indicate the programme session during which the accepted paper will be presented. It also refines the restriction on page length to indicate that published papers can only be up to 15 pages long. A token may now be defined which instantiates more than one of these classes. For example, if we also have a class {\tt ReceivedFinalVersion} of papers which have been received in camera-ready form, we can add to {\tt martian} additional information related to these aspects: \begin{quote}\begin{verbatim} TELL TOKEN martian IN AcceptedPaper, ReceivedFinalVersion WITH session : applicationsI dateReceived : 1989/2/3 END \end{verbatim}\end{quote} Note that {\tt martian} can have attributes ``induced'' by the attribute classes of {\tt AcceptedPaper} and {\tt ReceivedFinalVersion}. In the case of an attribute appearing in both classes, the value must be consistent with {\em both} class definitions. Concerning the interaction of subclass and instance-of hierarchies, we have, as usual, that instances of a class are also instances of its superclasses. In other words, if {\tt A ISA B} and {\tt C IN A}, then {\tt C IN B}. For representational structures that fully support classification (and therefore offer the dimension illustrated in Figure ~\ref{fig:semantic-net}) the reader may wonder whether {\tt A ISA B} and {\tt B IN C} implies {\tt A IN C}. For Telos, this implication is not supported because there seem to be cases where it is unwarranted. Consider, for example, the binary relations {\tt Spouse} and {\tt Wife}. Obviously {\tt Wife ISA Spouse} and {\tt Spouse IN SymmetricRelation}. However, we do not want to conclude here that {\tt Wife IN SymmetricRelation}. \subsection{Representation of Temporal Knowledge} \label{sec:time} Most application domains are not static: they exhibit a history of changes through time. A Telos model of a domain captures the full history of its evolution, rather than just the latest snapshot. For this, Telos adapts a framework for representing and reasoning with temporal knowledge proposed in \cite{Allen83}. This representation is based on the notion of an {\em time interval}, where seven exclusive temporal relations ({\tt equals, meets, before, overlaps, during, starts, ends}) and their inverses are used to characterize all possible relationships of two intervals on a linear time line. Thus, in contrast to temporal databases \cite{Snodgrass87}, Telos can represent incomplete information about time, e.g., a paper having been submitted sometime before 1989/2/2. Telos' modifications of this approach include (i) slight changes to the definitions of the thirteen temporal relationships, mostly dictated by language design considerations; (ii) incorporation of temporal constants, such as conventional dates and times (e.g., {\tt 1988/12/7} denoting December 7, 1988), semi-infinite intervals having conventional dates or times as one endpoint (e.g., {\tt 1986/10/25..*}), the infinite interval {\tt Alltime} and the special interval {\tt Now} denoting the current system time; (iii) restricting the power of temporal assertions that can be told to the system. With such a framework on hand, it is possible to represent temporal information as shown by the following revised definition of {\tt martian}: \begin{quote}\begin{verbatim} TELL TOKEN martian IN Paper ( at 1986/10..* ) WITH author firstAuthor: Stanley ( at 1986/10..* ); : LaSalle ( at 1987/1..* ); : Wong ( before 1987/5 ) title : `The MARTIAN system' END \end{verbatim}\end{quote} This operation introduces the token {\tt martian} in the knowledge base (we suppose it was not there already). The {\tt IN} clause makes {\tt martian} an instance of the class {\tt paper} for an unbounded time interval starting October 1986. Similarly, the {\tt WITH} clause asserts that {\tt Stanley} is the first author of {\tt martian} during the interval {\tt 1986/10..*}, {\tt LaSalle} is an author during the interval {\tt 1987/1..*} while {\tt Wong} was an author for some time before May 1987 (but we do not know the exact time). The corresponding attribute propositions (now 4-tuples) are shown below. \begin{quote}\begin{verbatim} [martian, firstAuthor, Stanley, 1986/10..*] [martian, ..., LaSalle, 1987/1..*] [martian, ..., Wong, T32] \end{verbatim}\end{quote} Henceforth, every attribute proposition {\tt p} has a {\em duration} component which can be accessed with the expression {\tt when(p)}. The history of the application domain can be modeled by augmenting KB facts with a {\em history time} i.e., an interval representing the time during which these facts are true in the application domain. History time is useful not only for tokens but also for generic propositions: for example, the {\em definition} ``personal deduction'' in an Income Tax Act, may only apply for this year. A KB records essentially the {\em beliefs} of the system, which may be distinct from the actual state of the world at that time. So, for example, the title of a paper might have been changed in March, but the KB is only told of it in May. Or we may make a correction to some previously told fact. Just like it represents the full history of an application domain, Telos also records the full history of its beliefs. For this reason, Telos represents {\em belief times}; these are intervals associated with every proposition in the knowledge base, which commence (technically speaking {\tt costart}) at the time when the operation responsible for the creation of the corresponding proposition was committed. All belief time intervals are assumed to be semi-infinite until the system is informed otherwise. So, once the system has been {\tt TELL}ed something, it keeps believing it, until it is explicitly required to revise its beliefs. The operations {\tt UNTELL} or {\tt RETELL} (see section \ref{sec:updates}) will cause precisely such belief revision. Thus, system beliefs ``persist'' until they are explicitly revised. Similar facilities have been proposed by \cite{Snodgrass87} for temporal databases. The syntax of the language, illustrated by the above example, is restricted in the sense that it only allows a single temporal relationship to appear in each of the temporal components of a given definition. This is in contrast with Allen's original framework where {\em sets} of relationships were allowed between time intervals (e.g., {\tt PaulsDateOfBirth (before during) 1975} in order to express further kinds of incomplete knowledge. Thus, after a series of definitions such as that for {\tt martian}, in Telos two intervals {\tt t1, t2} are either unrelated (i.e., any of the thirteen temporal relationships may hold between them) or are related through exactly one relationship. The reasons for this expressive retreat are strictly pragmatic: verifying the consistency of a network of temporal relations for Allen's algebra is NP-hard, as is computing all the consequences of a network. However, reasoning with certain subsets of the framework, including the one adopted here, is tractable \cite{Vilain-Kautz-vanBeek89}. %%%%%%%%%%%%%%%%% to go at in sec.8 probably \comment{ To recapitulate, the temporal modeling supported by Telos provides the following advantages: i) The use of intervals and predicates on them allows indefinite temporal information to be represented in a way which is not possible in traditional database models of time. This kind of modeling is essential for describing, for example, {\em possible} scenarios of activities in the world, as opposed to actins that have already occured. ii) The temporal language is deeply integrated with both the assertion language and the structural description of the KB. iii) Temporal aspects of generic information (e.g., schema and rule definitions) can finally be modeled as part of the description rather than just by performing update operations. iv) By distinguishing and automatically recording belief times, we obtain access to design decisions, ... } %%%%%%%%%%%%%%%%%% \subsection{Rules and Constraints} \label{sec:rules} A typed first order assertion sublanguage is offered as means for specifying {\em integrity constraints} and {\em deductive rules}. Well-formed formulas of this language are special objects in the Telos ontology and are allowed to appear quoted as attribute values of propositions. For example, the integrity constraint of the definition below ensures that an author cannot referee her own paper, while the deductive rule states that an author address is also a reply address. %%%%%%%% new page \newpage \begin{quote} {\tt TELL CLASS Paper IN SimpleClass WITH\\ \tb integrityConstraint\\ \tb\tb :\$ $\tt (\forall y/Person)\\ \tb\tb\ \ \ (y \in this.author \Then \neg (\exists t/Time)\; y \in this.referee\; [at\ t])$ \$\\ \tb deductiveRule\\ \tb\tb :\$ $\tt (\forall x/Paper)(\forall z/Address)\\ \tb\tb\ \ \ (z \in x.author.address \Then z \in x.replyAddress )$ \$ (at Alltime)\\ END } \end{quote} Note that deductive rules are constrained to be in a simple form to improve efficiency: the antecedent of the rule must be a conjunction of atomic formulas and the consequent must be a single positive atomic formula. \begin{figure} \vspace{5in} \begin{quote}\begin{verbatim} martian.author [during 1987/1] = {Stanley, LaSalle} martian.author [before 1988] = {Stanley, LaSalle, Wong} \end{verbatim}\end{quote} \caption{Examples of the use of the dot function} \label{fig:functions} \end{figure} The assertion language is naturally integrated with the existing framework by treating Telos classes as ranges for quantifiers. From a computational point of view, this choice offers some of the advantages associated with sorted logics \cite{Frisch89}. The following functions manipulate attributes and their values: \begin{itemize} \item The dot function {\tt x.l [r1 t1]} evaluates to the set of values of the attributes of proposition {\tt x} which belong to the attribute class labeled {\tt l} during intervals which are in relation {\tt r1} with {\tt t1}. \item The hat function {\tt x\verb#^#l [r1 t1]} evaluates to the set of values of the attributes of proposition {\tt x} with label {\tt l} during an interval which is in relation {\tt r1} with {\tt t1}. \item The bar function {\tt x|l [r1 t1]} evaluates to the set of attribute propositions with source {\tt x} which are instances of the attribute class labeled {\tt l} during intervals which are in relation {\tt r1} with {\tt t1}. \item The exclamation mark function {\tt x!l [r1 t1]} evaluates to the set of attribute propositions with source {\tt x}, label {\tt l} and duration which is in relation {\tt r1} with {\tt t1}. \end{itemize} The time constraint in the above functions are optional: if they are absent, appropriate defaults are adopted by the system. Figure \ref{fig:functions} shows the situation for the example in section \ref{sec:time}. Finally, the special identifier $\tt this$ is used as follows: an assertion $\tt \phi(this)$ defined on class {\tt C} is an abbreviation for $\tt (\forall x/C)\phi(x)$. Rules and constraints can be given history time intervals like any other attribute values, corresponding to periods during which the assertions hold in the knowledge base. Rules and constraints can also refer to history time explicitly. Integrity constraints must also be given a belief time: the time period during which the beliefs of the system are constrained. For example, if the above operation was processed on December 5, 1988, the integrity constraint included would enforce in every belief state after December 5, 1988 that no instance of the class {\tt Author} can be an author and a referee of the same paper\footnote{ Since no belief time is given for this integrity constraint, it is assumed that it constrains every belief state of the system from the time it was processed and on.}. These features can be exploited for activating and de-activating rules and constraints during certain times. In this way, we get facilities similar to triggers or deamons of active databases. \subsection{Querying the Knowledge Base} Telos offers the operations {\tt RETRIEVE} and {\tt ASK} for querying the knowledge base. {\tt RETRIEVE} uses only temporal and structural information to answer queries, while {\tt ASK} uses all the knowledge available. {\tt RETRIEVE} is a much more efficient operation, since only a few built-in inferences (e.g., inheritance) are performed. Both operations can be used either to prove that a closed formula of the assertion language follows from the knowledge base, or to find the propositions in the knowledge base that make a given formula true. \begin{quote} $\tt ASK\ :\ LaSalle \in martian.author\; [\!\Over 1988]\ BELIEVED \at 1989/1/1$ $\tt ASK\ x/Author:\ x \in martian.author \ TRUE \at 1987\ BELIEVED \at 1989/1/1 $ \end{quote} For example, when the above queries are evaluated against the current knowledge base, the system returns {\tt yes} and {\tt \{Stanley, LaSalle\}} respectively. %\linebreak\mbox{{\tt \{Stanley, LaSalle\}}} respectively. Queries can refer to history time explicitly (e.g., first query above). Alternatively, the optional clause {\tt TRUE} can be used to provide default history time for all unqualified atomic formulas in the query. The {\tt BELIEVED} clause identifies the belief times which are of interest to the user. When it is not present, the belief time is assumed to be {\tt Now} (i.e., the currently held beliefs are queried). \subsection{Updating the Knowledge Base} \label{sec:updates} The operations {\tt UNTELL} and {\tt RETELL} allow one to update the system's beliefs about certain historical relationships. As indicated already, updated information is not explicitly deleted from the knowledge base. Instead, the belief time intervals associated with such updated information are terminated. The {\tt UNTELL} operation can be used to specify that some of the instantiation, specialization, or attribute relationships of a proposition no longer hold. Suppose, for example, that Stanley changed his mind about authoring the Martian system on November 20th, 1986 and no longer wants his name associated with the paper. The following operation effects this update: \begin{quote}\begin{verbatim} UNTELL martian WITH author : Stanley ( at 1986/11/20..? ) \end{verbatim}\end{quote} As a consequence, if this operation was processed on December 9, 1989, its effect is to make the system believe as of December 9, 1989 that Stanley ceased being an author of {\tt martian} on November 20, 1986 (though it remembers him as an author in earlier belief states). Now the answers to the queries \begin{quote} $\tt ASK\ x/Author:\ x \in martian.author \ TRUE \at 1986/11/19 \ BELIEVED \at 1989/12/10 $ $\tt ASK\ x/Author:\ x \in martian.author \ TRUE \at 1986/11/21 \ BELIEVED \at 1989/12/10 $ \end{quote} will be {\tt \{Stanley\} } and the empty set respectively. The {\tt RETELL} operations amounts to a database update and can be semantically treated as the composition of an {\tt UNTELL} and a {\tt TELL} operation. Through {\tt RETELL}, the user can specify, for instance, that somebody's address changed. \section{Model Extensions Through Metaclasses} \label{sec:meta} Compared to other semantic models or knowledge representation languages, Telos appears to provide few features for capturing the semantics of applications. This section is intended to illustrate that additional structure can be introduced for particular categories of propositions through the mechanisms already offered by Telos. The first-class status of attributes and the ability to define attribute classes and metaclasses plays a particularly important role. Our point is that a relatively sparse framework can be used to accomplish a great deal. Let us consider again the IFIP Conference example. Conference organization involves many different kinds of documents, including various classes of papers, letters, announcements, memos and the like. To define common properties that various document classes have, we may want to introduce attribute metaclasses which support grouping of document attributes according to their semantic, deductive or other properties. One way to introduce these attribute metaclasses is through the metaclass {\tt DocumentClass}: %%%%%%%%new page \newpage \begin{quote}\begin{verbatim} TELL CLASS DocumentClass IN MetaClass WITH attribute source: AgentClass; content: SimpleClass; destination: AgentClass; typicalTurnaroundTime: TimePeriod IN SimpleClass END \end{verbatim}\end{quote} In this example, {\tt source, content} and {\tt destination} are labels of attribute metaclasses which may be instantiated for {\tt DocumentClass} instances\footnote{ To help the reader, we use identifiers ending with ``-Class'' for metaclasses.}. In this case, their effect is to group together semantically similar attributes, such as the attributes that describe the content of a document (e.g., title, abstract, keywords, text and so on) or the destination of a document (zero or more recipients, location/affiliation of the destination(s) and so on). The attribute label {\tt typicalTurnaroundTime} specifies a typical value for the length of time it takes for a document to be prepared and sent to its destination (say, one day for a letter, one month for a paper). Note that instances of {\tt typicalTurnaroundTime} are tokens and represent specific facts about their generic sources. Other {\tt DocumentClass} attributes, on the other hand, indicate the kinds of (attribute) classes that may be associated with a document class. {\tt DocumentClass} may also have arbitrary constraints expressed through assertions on its instances -- document classes, such as {\tt Paper} or {\tt Letter}. Thus, metaclasses constitute an important facility in the definition of generic objects, one that cannot be simulated by the use of the generalization hierarchy.\footnote{The grouping of conceptually related attributes illustrated above could also have been accomplished by the introduction of generalization hierarchies for attributes themselves, as in KL-ONE: {\tt title, abstract}, etc. are more specialized roles than {\tt content}. However, as we shall soon see, attribute classes provide additional facilities --- such as abbreviating constraints --- that cannot be achieved by attribute hierarchies.} The definition of the class {\tt Paper} might now be refined as \begin{quote}\begin{verbatim} TELL CLASS Paper IN DocumentClass WITH source author: Person content title: String ... turnaroundTime : 4weeks END \end{verbatim}\end{quote} Here, the attribute (class) {\tt [Paper, author, Person]} is an instance of {\tt [DocumentClass, source, SimpleClass]}, in a similar way that {\tt [martian, firstAuthor, Stanley]} is an instance of {\tt [Paper, author, Person]}. Thus attribute metaclasses can be thought of as {\em categories} for generic attributes associated with a class. As another example of use of attribute metaclasses, consider constraints on attribute values which are built-in in several semantic data models. One such constraint, let us call it the {\em Single} constraint, restricts an attribute to (at most) a single value. To define it, we introduce the attribute metaclass {\tt Single} whose instances are singleton attribute classes\footnote{The clause {\tt COMPONENTS} gives the source, label and destination of this attribute class.}. \begin{quote} {\tt TELL CLASS Single\\ \tb COMPONENTS [Class, single, Class] \\ \tb IN AttributeClass, MetaClass WITH\\ \tb\tb integrityConstraint\\ \tb\tb\tb :\$ $\tt(\forall u/Single) (\forall p,q/Proposition)\\ \tb\tb\tb\ \ \ (p \In u \And q \In u \And from(p)=from(q) \And\\ \tb\tb\tb\ \ \ when(p) \overlaps when(q) \Then p=q)$ \$\\ END } \end{quote} Literally, the above assertion states that for every instance of {\tt Single}, say {\tt u} (that is an attribute class), there are no two distinct instances {\tt p} and {\tt q} (these are attribute instances) with common source and overlapping times. Once this class has been defined, it can be exploited, through instantiation, to constrain the attributes of any other class, such as {\tt Paper}: \begin{quote}\begin{verbatim} single title: String \end{verbatim}\end{quote} If now {\tt martian} is an instance of {\tt Paper}, with a title specified by \begin{quote}\begin{verbatim} title :`The Martian system' \end{verbatim}\end{quote} then the constraint in {\tt Single} refers to attribute propositions like \begin{quote}\begin{verbatim} [martian, ..., `The MARTIAN system'] \end{verbatim}\end{quote} which are instances of {\tt [Paper, title, String]}, and decrees that there cannot be two such propositions with identical sources. Figure ~\ref{fig:single} illustrates the situation. Similarly, one can define an attribute metaclass {\tt Necessary} whose integrity constraint assures that each instance of some class for which the attribute is necessary, has at least one value for that attribute \cite{Mylopoulos-Borgida-Jarke-Koubarakis90}. \begin{figure} \vspace{3.5in} \caption{The constraint {\tt Single} on attribute {\tt title}} \label{fig:single} \end{figure} \subsection{Talking about Assertions} \label{sec:holds} To increase the extensibility of the language, we provide a way to talk about assertions. The resulting technique allows meta-level reasoning and is very powerful; we have however exploited this power only in defining attribute metaclasses. We introduce the predicate {\tt Holds} which is true whenever its argument is an assertion that follows from the KB. Recall that assertions appear in the KB, quoted, as parts of propositions: \begin{quote} $\tt [Paper,\ \ldots,\ ``(\forall x/Paper)(\forall y/Person)\ldots", Alltime]. $ \end{quote} In the definition of metaclasses, it is often useful to have constraints and rules which refer to formulas of the assertion language. Let us assume, for example, that we want to define an attribute metaclass {\tt PreCondition} and use it for specifying preconditions for certain activities. %%%%%%%%%%newpage \newpage \begin{quote} {\tt TELL CLASS PreCondition\\ \tb COMPONENTS [Class, preCondition, Assertion]\\ \tb IN AttributeClass, MetaClass WITH\\ \tb\tb integrityConstraint\\ \tb\tb\tb :\$ $\tt (\forall p/PreCondition)(\forall Obj/Proposition)(\forall t/Time)\\ \tb\tb\tb\ \ \ (Obj \In from(p) [\at t] \then (\exists HTime/Time) (HTime \overlaps t) \And\\ \tb\tb\tb\ \ \ Holds(to(p))))$ \$ \\ END } \end{quote} This attribute class constrains its instances to have destination components that are {\em open assertions} which follow from the knowledge base when their special variable {\tt Obj} is bound to an instance of the class they are associated with and {\tt HTime} is bound to an interval which overlaps the lifetime of this instantiation\footnote{ Note that $\tt t \overlaps t' $ implies that $\tt t \startsbefore t'$, in addition to the implication that the two intervals have a common subinterval.}. Open assertions can have at most two free variables, {\tt Obj} and {\tt HTime}, intended to be bound respectively to a proposition (the subject of the assertion) and a history time\footnote{ This binding is achieved through quantification in the constraint or rule which refers to the open assertion.}. Suppose then that the user specifies: \begin{quote} {\tt TELL CLASS Conference IN ConfEntityClass WITH\\ \tb\tb attribute\\ \tb\tb\tb budget: Money\\ \tb\tb preCondition\\ \tb\tb\tb :\$ $\tt Obj.budget \ge 10000\ [\!\at HTime ] $ \$ \\ END} \end{quote} This operation defines the class {\tt Conference} and asserts the proposition \[ \tt [Conference,\ \ldots,\ ``Obj.budget \ge 10000\ [at\ HTime]",\ ...] \] in the knowledge base. This proposition becomes an instance of {\tt Precondition}. Now the above integrity constraint will be satisfied if every time an instance of {\tt Conference} is constructed, its {\tt budget} value exceeds \$10,000. Analogous definitions can be given for other attribute metaclasses such as {\tt PostCondition}, {\tt ActivationCondition} and {\tt Invariant} with obvious semantics \cite{Mylopoulos-Borgida-Jarke-Koubarakis90}. In general, our language enables us to define metaclasses which represent concepts that are appropriate for a particular application domain. For instance, if it is deemed that the concept of {\em activity} is useful for modeling conferences, we may want to adopt SADT's\footnote{SADT is the trademark of SofTech Inc.} notions of {\em input, output} and {\em control}, referring to entities that are consumed, produced or used without state change by an activity: \begin{quote} {\tt TELL CLASS ActivityClass IN MetaClass WITH\\ \tb\tb attributes\\ \tb\tb\tb agent: AgentClass;\\ \tb\tb\tb input: EntityClass;\\ \tb\tb\tb output: EntityClass;\\ \tb\tb\tb control: EntityClass;\\ \tb\tb\tb part: ActivityClass\\ \tb\tb integrityConstraint\\ \tb\tb\tb inputExists:\$ $\tt (\forall p/Proposition)(\forall x/Token)(\forall t1/Time)\\ \tb\tb\tb\tb\tb (p \In this|input \And x \In from(p)[at\ t1] \then\\ \tb\tb\tb\tb\tb (\exists q/Attribute)(\exists t2/Time)(q \In p \And\\ \tb\tb\tb\tb\tb to(q) \In to(p)[at\ t2] \And t2 \overlaps t1))$ \$; \\ \tb\tb\tb outputCreated: ...\\ \tb\tb\tb controlRemains: ...\\ \tb\tb\tb partDuringWhole:\$ $\tt (\forall p/Proposition)(\forall x/Token)(\forall t1/Time)\\ \tb\tb\tb\tb\tb (p \In this|part \And x \In from(p) [at\ t1] \then (\exists q/Attribute)\\ \tb\tb\tb\tb\tb (\exists t2/Time)(q \In p [at\ t2] \And from(q) = x \And t2 \during t1))$ \$; \\ \tb\tb\tb partInputConsistency: ...\\ \tb\tb\tb partOutputConsistency: ...\\ END } \end{quote} The {\tt inputExists} constraint checks that inputs exist at the start of an activity and cease to be instances of their respective input types before the end of an activity. Likewise, the {\tt partDuringWhole} constraint declares that components of an activity occur during the activity. Note that RML too, \cite{Greenspan84}, offers the notion of activity defined above. However, RML has these notions {\em built-in} and is therefore less adaptable to applications where these notions need slight or major changes. Suppose that one wishes to base requirements modeling on the notion of {\em role} rather than that of activity, following \cite{Pernici89}. For RML such a change of perspective amounts to a total discard. For Telos it simply means that a different set of individual and attribute metaclasses needs to be defined. Specific activities can now be modeled in the intended application domain. A final example of a useful attribute metaclass is {\tt Rep}. It can be used to constrain two classes to have isomorphic extensions. \begin{quote} {\tt TELL CLASS Rep\\ \tb COMPONENTS [Class, rep, Class]\\ \tb IN AttributeClass, MetaClass WITH\\ \tb\tb integrityConstraint\\ \tb\tb\tb :\$ $\tt (\forall x/Proposition)(x \In from(this) \then \\ \tb\tb\tb\ \ \; (\exists ! p/Proposition) (p \In this \And x = from(p)))\\ \tb\tb\tb\ \ \And (\forall y/Proposition)(y \In to(this) \then \\ \tb\tb\tb\ \ \; (\exists ! p/Proposition (p \In this \And y = to(p)))$ \$\\ END } \end{quote} In the above definition ``$\tt \exists !$'' stands for ``there exists unique''. Thus if \begin{quote}\begin{verbatim} [ConferenceOrganization, ..., ConfRecord, ...] \end{verbatim}\end{quote} is an instance of {\tt Rep}, there is a one-to-one correspondence between the instances of the two classes (though corresponding instances need not have identical time intervals). {\tt Rep} is useful for expressing accuracy and completeness requirements on the contents of an information system, as we will see in the following section. %\subsubsection{A farewell example} % %\begin{figure} % %\begin{quote} %{\tt %TELL CLASS ConferenceOrganization \tb IN ActivityClass \tb WITH\\ %\tb\tb input,single\\ %\tb\tb\tb budg: Budget;\\ %\tb\tb output,single\\ %\tb\tb\tb conf: Conference;\\ %\tb\tb\tb finalReport: Report\\ %\tb\tb control, single\\ %\tb\tb\tb nm: Name\\ %\tb\tb\tb orgCommittee: Committee;\\ %\tb\tb\tb startTime, endTime: Date\\ %\tb\tb control\\ %\tb\tb\tb sponsors: Organization;\\ %\tb\tb part, single\\ %\tb\tb\tb setSchedule: SetTimeSchedule;\\ %\tb\tb\tb setPC: AppointProgrammeCommittee;\\ %\tb\tb\tb setLAC: AppointLocalArrangementsCommittee;\\ %\tb\tb\tb mkLA: MakeLocalArrangements;\\ %\tb\tb\tb mkProgramme: MakeProgramme;\\ %\tb\tb\tb holdConf: HoldConference;\\ %\tb\tb part\\ %\tb\tb\tb genExpenseReport: GenExpenseReport\\ %\tb\tb preCondition\\ %\tb\tb\tb : BudgetAccepted(this)\\ %\tb\tb activationCondition\\ %\tb\tb\tb :\$ Now during Obj.budg.startDate \$\\ %\tb\tb postCondition\\ %\tb\tb\tb :\$ budg.amountLeft = 0 \$\\ %\tb\tb terminationCondition\\ %\tb\tb\tb :\$ Now after Obj.budg.endDate \$\\ %\tb\tb integrityConstraint\\ %\tb\tb\tb :\$ $\tt setSchedule \before setPC \And setSchedule \before setLAC %$ \$\\ %\tb\tb\tb\tb\tb\tb \% subactivities other than genExpenseReport\\ %\tb\tb\tb\tb\tb\tb \% are linearly ordered\\ %\tb\tb\tb :\$ $\tt (\forall t/Time)(x \during when(this) \then (\exists %y/GenExpenseReport)\\ %\tb\tb\tb (when(y) \startsafter when(x) \And when(y) \Tendsbefore x+6month))$ %\$ \\ %END } %\end{quote} % %\caption{The definition of {\tt ConferenceOrganization}} %\label{fig:confOrg} %\end{figure} % %Consider the global activity of conference organization whose definition %is given in Figure ~\ref{fig:confOrg}. According to this definition, {\tt %ConferenceOrganization} instances are endowed with a budget which they %consume, produce a conference and a final %report, consist of several subactivities and satisfy a number of constraints, %including a linear ordering of their major subactivities ({\tt setPC, %setLAC, ...}) and their {\tt GenExpenseReport} subactivities. %{\tt ConferenceOrganization}s begin on the start date of their budget, on the %condition that the budget has been approved, and end on the date their budget %expires. % M.J. : Summary of my changes, version of June 18, 1990 % I have simplified and reduced the Telos texts without changing % the spirit of the examples. The second screendump was removed. % In several places (typically at the end of subsections), I have % added brief summaries of actual experiences with using Telos % related to that section. I have also added references for most % of these experiences, and listed them at the end of the text. % If you think there are too many references, take them out again. % But I thought this would give a good picture of the rather substantial % experience we and others have had with the language. % % Changes in version of June 18, 1990: % To simplify further the syntax of models, I took out the four % metametaclasses at the beginning -- they were wrong anyway! The way % how they are instantiated in the examples, they must be Omega-Classes. % Also, I tried to model the Conversations a bit more elegantly, using % multiple inheritance. Otherwise, a few unnecessary sentences have been % cut. Finally, I suggest to take out uniformly the reference GS86 % and replace it by the more recent Haidan-Meyer90 paper. % The usage world example is still in but could be taken out if more % cuts are needed. % IMPORTANT: The definition of Rep must remain in section 3, I use it! % % Changes of June 30: % Following a request by Alex, I have taken out several references % to specific applications, leaving in just the most important ones. % No longer there are: Schoger (construction), Steinke (security), % Hahn et al 89 (CoAUTHOR), Buchan (Taxis). It is up to you which % version you wish to use -- I personally felt that these references % give some credibility to the usability of Telos. \section{Representing Knowledge About Information Systems} \label{applications} After obtaining a basic understanding of Telos, we can now look at its application in developing knowledge bases about software. In particular, we present examples of using Telos in describing and then applying a rather powerful metamodel for knowledge relevant to the development of information systems. Traditionally, database engineering has made the (tacit) assumption that an information system is supposed to capture some excerpt of world history, and hence has concentrated on modeling (i.e., ``capturing information about'') the application domain. This practice provides an answer of sorts to the fundamental question ``What does the information handled by my system mean?''. Unfortunately, it also tends to draw attention away from a number of equally fundamental questions, concerning other types of knowledge about an information system. The section begins with a basic taxonomy of distinct ``subworlds'' about which knowledge needs to be recorded during the development of an information system. The distinction between the different subworlds is illustrated with definitions drawn from the IFIP Conference example \cite{Olle-Sol-VerjinStuart82}. \begin{itemize} \item The {\em subject world} is the domain about which the proposed information system is to provide information; this world may be an organizational environment, say a department store, or something completely different, say a world of chemical experiments or geopolitical games. Consequently, the set of appropriate concepts for representing this world may vary considerably. For the purposes of our running example, the proposed information system does maintain information about an organizational setting. The notions of {\em activity} and {\em entity} will be assumed to be appropriate for modeling such a world. \item The {\em system world} includes specifications at different levels of implementation detail on what the information system does. The nature and the number of specification levels depends on the development methodology adopted. For instance, the levels may include functional requirements, conceptual designs and implementations. For each level, appropriate concepts need to be defined and made part of the system world metamodel. To keep our running example (somewhat) manageable, we limit the discussion of system world modeling to functional requirements only. As part of the system world, one may want to prescribe correspondences between the information maintained by the information system and the intended subject world. It might be specified, for instance, that the system's record of conferences is complete (for every conference, there is an entry in the system's records) and accurate (there are no entries in the system's records that do not correspond to an actual conference) through the use of attribute metaclasses such as {\tt Rep}. \item The {\em usage world} describes the environment within which the system is embedded. Such descriptions often take the form of input/output relationships, but may also include the different classes of (end) users of the intended system or the kinds of interfaces supported by the system (represented, to a first approximation, as activities having the system and one or more users as co-agents). The usage world may also include descriptions of the organizational environment within which the system will function, including office procedures. Advanced usage worlds may even include user modeling, e.g., what does each class of users know about the subject and system worlds, how often do they use the system, and the like. \item The {\em development world} focuses on the entities and activities which arise as part of the design process itself. These would include the composition of the design team, responsibilities of each team member, design decisions, development tools, supporting documentation, etc. For example, there may be a standard procedure by which an existing version of the conference management system is adapted to the needs of a specific conference, using a specific development team hired by IFIP and a specific software development environment. \end{itemize} \comment{ SubjectWorld ''...places and kings...'' How is info about SubjectWorld handled within the Usage World? /\ ------------------- \ / \ UsageWorld----user interfaces \ what do the IS databases users \ \say about the SubjectWorld? user models \ \ environmental activities \ \ \ \---- \ \ -----SystemWorld (3 levels) Justifications of / |FunctionalReqs development goals design decisions |Design in terms of desired / |Implementation UsageWorld state / \ / \ / DevelopmentWorld development team. schedule non-functional requirements development process } \begin{figure} \vspace{5in} \caption{Knowledge about Information Systems} \label{fig:worlds} \end{figure} One of the obligations of a knowledge representation system is to provide guidance on the organization of the knowledge at hand as well as the process to be used by the knowledge engineer to build up his knowledge base. Figure ~\ref{fig:worlds} illustrates the basic ``worlds'' as well as the kinds of knowledge that might relate them. The rest of the section illustrates features of Telos by suggesting possible ontologies for each of the above worlds, and occasionally instantiating it for the IFIP domain. We emphasize that the discussion in this section is intended to illustrate the flexibility of Telos in modeling drastically different worlds, a flexibility derived primarily from its classification dimension and the treatment of attributes. Nevertheless, the examples presented {\em are}, in fact, based on actual application of Telos, mostly in the context of ESPRIT project DAIDA, where a complete prototype environment for information systems engineering was constructed, generally following the approach outlined here \cite{Jarke-Mylopoulos-Schmidt-Vassiliou90}. \subsection{The Subject World} An essential aspect of information system development is the characterization of the domain about which information will be maintained -- a characterization which needs to be explicitly recorded. A number of different general approaches could be followed in gathering and recording this information, including Structured Analysis, Entity-Relationship-Activity, etc. These approaches can be defined within Telos. We could even extend them with concepts about a particular application domain, e.g., accounting systems, to cover the use of standard requirements. Some real-world experiences with domain modeling have been gained with a commercial implementation of an early Telos version \cite{Haidan-Meyer90}. For an example, we continue with the definition of a subset of the notions of RML \cite{Greenspan84} begun in section ~\ref{sec:meta}. As indicated earlier, RML's basic structures are loosely based on SADT \cite{Ross-Schoman77}; this was motivated in part by the idea of using SADT as a graphical road map which sketches the requirements model before filling in the more formal semantic details. RML provides the three basic mechanisms of Activities, Entities, and Assertions. Since the latter are already available in the Telos kernel, we need to concern ourselves only with {\em activities} and {\em entities.} The definition of {\tt ActivityClass} presented in the previous section can be used as is. The definition of {\tt EntityClass} follows: %%%%%%%%%%newpage \newpage \begin{quote} {\tt TELL CLASS EntityClass IN MetaClass WITH \\ \tb attribute\\ \tb\tb producer, consumer: ActivityClass;\\ \tb\tb part, association: EntityClass\\ \tb integrityConstraint\\ \tb\tb producedByProducer :\$ $\tt (\forall x/Proposition) (x \In this \then\\ \tb\tb\tb (\exists y/Proposition) (\exists p,q/Attribute)(y \In this.producer \And\\ \tb\tb\tb from(p) = y \And to(p) = x \And p \In q \And q \In y.output))$ \$\\ END } \end{quote} Every instance of an entity class is produced by a producer activity. Note the (pleasing) duality between entities and activities, initially offered in SADT. Since entities and activities {\em per se} can be seen as fundamental concepts in describing human activities, and hence will appear in the other subworlds, we will in fact use the generalization hierarchy to place {\tt EntityClass} and {\tt ActivityClass} in {\tt ISWorldClass}, rather than just {\tt SubjectWorldClass}. Returning to conference organizing, one can then start modeling the domain by considering specific classes of entities and activities, such as the following. \begin{quote}\begin{verbatim} TELL CLASS SubmittingAPaper IN ActivityClass WITH output sentIn: PaperSubmitted; submissionLetter: Letter input prepared: PaperWritten control sender: Person; recipient: Person; conference: Conference integrityConstraint samePaper: $ this.prepared = this.sentIn $; submissionOnTime: $ when(this) before this.conference.deadline $; rightRecipient: $ this.recipient = this.conference.programChair $ END \end{verbatim}\end{quote} %%%%%%%%%%newpage \newpage \begin{quote} {\tt TELL CLASS Paper IN EntityClass WITH\\ \tb producer\\ \tb\tb paperwriting: Writing\\ \tb consumer\\ \tb\tb submitting: SubmittingAPaper\\ \tb part\\ \tb\tb title: String;\\ \tb\tb pages: 1..12\\ \tb association\\ \tb\tb author: Author;\\ \tb\tb conference: Conference\\ \tb deductiveRule\\ \tb\tb rightconference :\\ \tb\tb\tb \$ $\tt c \in this.submitting.conference \then c \in this.conference$ \$\\ END } \end{quote} In the DAIDA project, Telos-based subject world ontologies have been used to build graphical frontends for requirements engineering which give the developer well-known visualizations such as SADT diagrams but have a precise formal background. This formal background can be further exploited to integrate other views of the same information system (e.g., Entity-Relationship). \subsection{The System World} One possible view of an Information System is as a world with its own specific entity and activity classes -- often called {\em data} and {\em transactions}. An important specific characteristic of information systems that their data and activity classes are often related to objects and activities in the subject world. Continuing our example, we use a set of system classes that follows the style of Taxis \cite{Mylopoulos-Bernstein-Wong80}. System activity classes are called transactions and can have only data classes (a special kind of entity classes) as inputs and outputs. In defining the representation relationship, we leave a lot of room for design decisions; for example, data classes can either represent subject world entities (e.g., data about referees and referees themselves), or traces of subject world activities (e.g., a class {\tt AuthorKitMailReceipts} tracking the activity of mailing out forms to authors), or a mixture. %%%%%%%%%%newpage \newpage \begin{quote}\begin{verbatim} TELL CLASS TransactionClass ISA ActivityClass WITH attribute input, output: DataClass rep activitybytransaction: ActivityClass END TELL CLASS DataClass ISA EntityClass WITH attribute producer, consumer: TransactionClass rep activitybydata: ActivityClass; entitybydata: EntityClass END \end{verbatim}\end{quote} Given this specification context, one can now start defining the model of the data base at the semantic level, by defining a variety of subclasses of {\tt DataClass} and {\tt TransactionClass.} This process is sufficiently familiar that we will not detail it further here. \subsection{The Usage World} The usage world model is intended to describe the man-machine interactions supported by the information system and the context within which they take place. Depending on the kind of usage environment, such models have been investigated in office research, computer-integrated manufacturing and similar fields of study which involve the integration of information technology with its environment. A natural description of the usage world can also be given in terms of activities and entities. In fact, subject and usage world have not been traditionally distinguished. Although this is not the place to argue the issue in full, we believe that the distinction is evident in certain domains: e.g., contrast the world of agriculture, involving farming, weather, produce, etc., and the information management activities about farming which occur in the Department of Agriculture. The distinction is crucial in clarifying various, potentially conflicting needs that the information system must fulfil. For the IFIP example, the subject world contains authors, paper submission, referees and the like, whereas the usage model talks about office staff and office tasks such as writing acknowledgments or selecting referees. Additionally, the usage model can exploit the fact that usage activities (both manual ones and man-machine interactions) may be constrained by plans or bureucratic procedures that involve issues such as precedence, priority and security. In modeling these aspects, we shall make use of the specialization abstraction in Telos. Usage world activity classes are specialized activity classes for which an agent is known (it can be a person, a system, or a team composed of both persons and systems) and which can be subject to certain precedence constraints; also, usage world activities may have to satisfy goals set by their supervisors, and these goals may influence the representation mapping between subject world and system world. \begin{quote} {\tt TELL CLASS UsageActivityClass ISA ActivityClass WITH\\ \tb attribute\\ \tb\tb agents: AgentClass;\\ \tb\tb supervisor: UserClass;\\ \tb\tb precedes: UsageActivityClass;\\ \tb\tb goals: Goals\\ \tb integrityConstraint\\ \tb\tb precedence:\\ \tb\tb\tb\$ $\tt (\forall preclink/Proposition) (preclink\ in\ this|precedes \then \\ \tb\tb\tb\ \ when(from(preclink))\ before\ when(to(preclink))) $ \$\\ END\\ } \end{quote} \begin{quote}\begin{verbatim} TELL CLASS Goals ISA EntityClass END TELL CLASS AgentClass IN MetaClass WITH attribute member: AgentClass END \end{verbatim}\end{quote} The representational relationships between system world and subject world can be related to the usage world by qualifying these relationships with the goals followed when determining the system requirements. These goals can be both functional (covering the functionality required by the application domain) or non-functional (performance, accuracy, etc.). In Telos, this can be accomplished quite easily by attribution of attributes, one of the unique features of the language: %%%%%%%%%%newpage \newpage \begin{quote}\begin{verbatim} TELL CLASS TransactionClass!repbytrans IN Class!rep WITH attribute mappingGoal: Goals END \end{verbatim}\end{quote} % This example is too long I think. Do we need any part of it? % M.J.: If we are short of space, this example can be dropped completely!!! The following is an example of one usage class defined: \begin{quote} {\tt TELL CLASS WriteAcknowledgment IN UsageActivityClass WITH\\ \tb output\\ \tb\tb letter: Letter\\ \tb control\\ \tb\tb sender: Person;\\ \tb\tb recipient: Person;\\ \tb\tb submission: SubmittingAPaper\\ \tb agents\\ \tb\tb letterprogram: DesignTask1\\ \tb supervisor\\ \tb\tb programChair: Person\\ \tb precedes \\ \tb\tb: SendToReferees\\ \tb integrityConstraint\\ \tb\tb chairperson: \\ \tb\tb\tb \$ this.submission.conference.programChair = this.programChair \$;\\ \tb\tb rightpersons: \\ \tb\tb\tb\$ $\tt this.sender=this.programChair \And this.recipient = this.submission.sender $\$;\\ \tb\tb acknowledgmentWithinAWeek: \\ \tb\tb\tb\$ $\tt when(this)\ before\ when(this.submission) + 7$ \$ \\ END } \end{quote} We do not detail the modeling of agents at this point. A more elaborate metamodel could incorporate some basic cognitive constraints on agents which guide the activities they participate in. It could also describe the organizational structure of agents, their access rights, etc. Telos users have actually developed several such models, e.g., for purposes of security specification, for a co-authoring system, for contract negotiation support in public construction projects, even for modeling paradigm shifts in the history of natural science. \subsection{The Development World} The development world sees the information system as a design object to be worked on. Typically, the management of software development is organized in layers. Single-worker tasks involving detailed knowledge about individual languages, methodologies, and tools are called programming-in-the-small. Tasks involving the negotiation and coordination of multiple programmers are called programming-in-the-many. In between, object management tasks such as version and configuration management are the domain of programming-in-the-large \cite{Rose-Jarke90}. Here, we only sketch an in-the-small and an in-the-many model. In a Telos model used intensively throughout DAIDA \cite{Chung89} \cite{Jarke-Jeusfeld-Rose90} programming-in-the-small is understood as a set of interrelated design decisions which transform design objects into other design objects, supported by design tools. Design tools are modeled by the special kinds of design decisions they support. Design goals are a special kind of design objects which provide a rationale for design decisions. \begin{quote}\begin{verbatim} TELL CLASS DesignObject ISA EntityClass END TELL CLASS DesignGoal ISA DesignObject, Goals END TELL CLASS DesignDecision ISA UsageActivityClass WITH attribute input: DesignObject; output: DesignObject; agents: DesignTool goals: DesignGoal; END TELL CLASS DesignTool ISA AgentClass WITH attribute qualification: DesignDecision END \end{verbatim}\end{quote} For the IFIP example, a design decision could concern the choice of a particular standard package for a task defined in the system model. This could be led by the goal of saving development costs, and could have been proposed by an outside consulting firm. More generally, design decisions may involve the refinement of existing models, the mappings between various representational formalisms, the versioning of existing design objects, and the configuration of complex systems from reusable components. In the DAIDA project, this model has been used to formalize and manage the integration of multiple languages, methods, and tools of the DAIDA environment \cite{Jarke-Jeusfeld-Rose90}. The same model has also been used to represent a bootstrapping process by which an implementation of the full Telos language was derived from a small kernel \cite {Jarke-Jeusfeld-Rose89}. To organize programming-in-the-many, we start from the concept of Agent introduced in the Usage World. To this concept, we simply add a possibility that these agents can communicate about design decisions according to some protocol. \begin{quote}\begin{verbatim} TELL CLASS ConversationClass ISA UsageActivityClass WITH attribute content: DesignDecision integrityConstraint :$ size(this.agents) >= 2 $ END \end{verbatim}\end{quote} The constraint says that any conversation model should foresee at least two kinds of roles for agents; it can be satisfied by any message protocol that knows of senders and receivers, for example. One possible instance of such a metamodel is Winograd's \cite{Winograd-Flores87} conversation-for-action protocol. The model below specializes the topics of conversation to be formal tasks in developing software according to our in-the-small methodology. Note also the usage of multiple inheritance. \begin{quote}\begin{verbatim} TELL CLASS Message IN ConversationClass WITH agents sender: ProjectMember; recipient: ProjectTeam END \end{verbatim}\end{quote} \begin{quote} {\tt TELL CLASS Response ISA Message WITH\\ \tb attribute, necessary\\ \tb\tb reference: Message\\ \tb integrityConstraint\\ \tb\tb personsright:\$ $\tt this.reference.sender = this.recipient \And\\ \tb\tb\tb \ \ \ \ \ \ \ \ \ \ \ \;this.reference.recipient = this.sender $ \$\\ END } \end{quote} \begin{quote}\begin{verbatim} TELL CLASS MappingRequest ISA Message WITH content mappingtask: MappingDecision END TELL CLASS MappingPromise ISA Response WITH attribute, necessary reference: MappingRequest content, necessary mappingtask: MappingDecision integrityConstraint taskright: $ this.reference.mappingtask = this.mappingtask $ END \end{verbatim}\end{quote} This excerpt covers the first part of a conversation for action. The constraints say that, if one partner promises a request put to him, this partner has (counter it or) to accept it exactly as is. Conversation primitives such as Counter and Accept can be modeled in a similar fashion. In the Telos-based software information system, ConceptBase \cite{ConceptBase89}, the full model has been implemented. The implementation has been applied to several software development examples, including management of a large programming class. Figure \ref{fig:DesignerProgrammer} is a screendump from such a session; the graphical browser documents the status of a subcontracting conversation between a designer and a programmer concerning the redesign of a program. \begin{figure} \vspace{4in} \caption{A contracting conversation between a designer and a programmer} \label{fig:DesignerProgrammer} \end{figure} The design of a sophisticated Telos-specified project management system which also takes into account the proactive organization and reorganization of ill-structured projects is reported in \cite{Srikanth-Jarke89}. ConceptBase also offers a graphical ``argument editor'' which supports the real-time or asynchronous discussion within a distributed software development team \cite{Hahn-Jarke-Rose90}. This editor is based on another instance of ConversationClass inspired by Toulmin's model \cite{Toulmin58}, and is similar to the gIBIS tool developed by MCC \cite{Conklin-Begeman88}, with the important difference that the topic of discussion is formally known to the system. Initial application experiences indicate that such an editor may be a valuable tool for recording the rationales of design decisions; formal experiments to evaluate this claim are being prepared. Note how the ConceptBase system associates different shapes and colors with the metaclasses defined above. In Figure \ref{fig:DesignerProgrammer}, the agents are shown in white ovals, and the aggregation of messages in a conversation is made explicit. The flexibility of user-defined metaclasses in Telos requires tools for interactively defining such mappings between knowledge base objects and their graphical representations. Formally, this mapping can be described by Telos deductive rules \cite{Jarke-Jeusfeld-Rose89}. \subsection{ Discussion} In this section, we have proposed a multi-perspective approach to the representation of knowledge about information systems. For space reasons, we could only briefly reference actual experiences with using Telos for each of these perspectives and for their integration, gained by our own research groups as well as by industrial partners and various outside users and students. These experiences lead us to believe that a number of Telos features make it especially suitable for the task of representing knowledge about information system development. First, the by--now--standard approach of modeling a domain using objects related by attributes, grouped into classes that are organized into subclass hierarchies, provides the usual benefits of organizing and abstracting information. The possibility of viewing classes as objects, themselves grouped into (meta)classes, allows the description itself to be structured in useful ways, as in the case of the different subworlds. The treatment of attributes as first-class objects has also proven very useful for two reasons. It does not force us to commit ourselves at the point of first definition of an object how it is going to be used since, e.g., new attributes can be associated with any Telos proposition. Further, attributes of attributes can be the most compact and natural representation for structures such as design dependencies (e.g., the dependency {\tt TransactionClass!repbytrans} in the UsageWorld) which have to be represented much more awkwardly in other languages. We have included in the presentation a screendump to illustrate how the structural orientation of Telos, supported by the uniform treatment of individuals and attributes, allows a graphical representation of the knowledge base which can be usefully exploited in providing a nice user interface for developers. In particular, hypertext-like interfaces are natural for semantic network-style representation schemes \cite{Biggerstaff-Perlis89}, and allow developers to ``navigate'' through the knowledge base to explore its contents. Finally, the explicit distinction between and availability of both domain-time and development-time in Telos allows not just historical reference in the subject world, but the ability to rationalize chronologically the evolution of the software design -- an important capability during software maintenance, which is the most cost- and work-intensive part of the software life-cycle. In summary, our experiments as well as initial experiences by other users have shown that Telos elegantly covers many of the requirements for representing knowledge about information systems. %%%%%%%%%%%%%%%%% \comment{ REFERENCES I propose to take out the reference to Jarke-Rose 88 (SIGMOD), and replace it throughout by the reference Jarke-Jeusfeld-Rose 90: Jarke, M., Jeusfeld, M., Rose, T. (1990). A software process data model for knowledge engineering in information systems. Information Systems 15, 1, 86-115. I also propose to take out the reference KMSJ since it does not contain more information than the present paper. Similarly, only one version of KMSB should be cited, same for implementation papers. Also, I have added citations of the following references for actual uses of Telos in the above text of sec 4 Hahn, U., Jarke, M., Rose, T. (1990). Group work in software projects. Proc. IFIP WG 8.4 Conference on Multi-User Applications and Interfaces, Iraklion, Greece, Sept. 24-26, 1990. The following should replace Gallagher-Solomon86: Haidan, R., Meyer, R. (1990). Requirements modeling and system specification in a logic-based knowledge representation framework. Report, ESPRIT project 892 (DAIDA), SCS Informationstechnik, Hamburg, Germany. Jeusfeld, M., Mertikas, M., Wetzel, I., Jarke, M., Schmidt, J.W. (1990). Database application development as an object modeling activity. Proc. 16th Intl. Conf. Very Large Data Bases, Brisbane, Australia. % references below not quoted anymore in version of June 30 Schoger, G. (1990). The role of knowledge-based systems in marketing investment goods. Diploma thesis (in German), Dept. Economics, University of Passau, Germany. Steinke, G. (1990). Design aspects of access control in a knowledge base system. Proc. 12th SECURICOM. Paris, France, March 1990 (to appear in Computers & Security). }  \section{Some Formal Aspects of the Telos System} \label{sec:formalization} A formal account of a new language concisely expresses the meaning of the various language constructs in a thorough and organized manner. Indeed, with Telos, as with many other languages, ambiguities and inconsistencies were discovered during the process of constructing a formal account of the language. In addition, such an account can serve as point of contact between the language designers, implementors, end-users and critics. Following \cite{Brachman-Levesque86}, we describe a Telos knowledge base in terms of its functional behaviour at the knowledge level for operations such as $TELL$ and $ASK$. A Telos knowledge base is described in part (though not implemented) as a collection of (historical) first-order theories, indexed by belief times\footnote{ Since belief times are constant, they can be represented by semi-open intervals of the form $[a,b)$ or $[a,+\infty)$, where $a$ and $b$ are atomic point-like intervals -- days in the discussion of the previous sections.}. Intuitively, each one of these theories corresponds to the beliefs of the system during some time period (the index of the theory). Knowledge base operations are then treated as functions defined over indexed theories, and other things. For details omitted in this section, see \cite{Koubarakis-Mylopoulos-Stanley-Borgida89} and \cite{Mylopoulos-Borgida-Jarke-Koubarakis90}. Each historical theory is constructed in the following way: Start with a first-order logic with types augmented with axioms for {\it isa}, {\it in}, time entities, etc; each historical theory constructed will be a theory in this logic. All such theories include a group of axioms which in some sense ``define'' what is a well-formed knowledge base; in addition, every $TELL$ operation introduces additional axioms. Finally, $ASK$ operations invoke certain default assumptions to provide answers to queries. The formal account of this section offers a proof theory as definition of ``consistency'' and ``question-answering''. By translating Telos expressions into a standard first order logic, we get a model theory as a bonus. \subsection{Initial Theory} \label{sec:initial-theory} \subsubsection{The Target Language $\cal L$} The language we use, $\cal L$, is a first order logic with equality, with the additional restriction that all quantifiers have restricted ranges. The basic types/ranges of $\cal L$ are $Proposition$, $Time$ and $Class$. For any particular knowledge base, all class names appearing in it can also be used as ranges for quantifiers. $\cal L$ also contains the following predicates and function symbols: \begin{itemize} \item The 5-place predicate symbol $prop$ used to describe the components of every Telos proposition formally. The first four arguments of $prop$ are of type $Proposition$; the last argument is of type $Time$. \item The 1-place function symbols $from, label, to$ and $when$ used to map propositions to their components. \item The 3-place predicate symbols $in$ and $isa$ used to describe instances and subclasses respectively. The type of $in$ is $Proposition \times Class \times Time$; the type of $isa$ is $Class \times Class \times Time$. \end{itemize} \subsubsection{Axioms} \label{sec:axioms} Time is axiomatized using Allen and Hayes' proposal \cite{Allen-Hayes89}, modified to reflect the Telos conventions. Other axioms in our theory include: \noindent {\em Axiom for proposition components:} \begin{quote} $(\forall p,x,y,z/Proposition)(\forall t/Time)(prop(p, x, y, z, t) \then$ \\ $from(p) = x \myand label(p) = y \myand to(p) = z \myand when(p) = t)$ \end{quote} \noindent {\em Transitivity of IsA}\footnote{The intersection of two time intervals $t_1$ and $t_2$ (i.e., the time period common to both) is denoted by $\tt t_1*t_2$.}: \begin{quote} $(\forall p_1,p_2,p_3/Class)(\forall t_1,t_2,t_3/Time)$ $(isa(p_1, p_2, t_1) \myand isa(p_2, p_3, t_2) \myand$ \\ $t_3=t_1*t_2 \then isa(p_1, p_3, t_3))$ \end{quote} \noindent {\em Specialization Postulate}: The extension of a class is a superset of the extension of any of its subclasses. \begin{quote} $(\forall p_1,p_2,p_3/Proposition)(\forall t_1,t_2,t_3/Time)$ $(in(p_1, p_2, t_1) \myand isa(p_2, p_3, t_2) \myand$ \\ $t_3=t_1*t_2 \then in(p_1, p_3, t_3))$ \end{quote} \noindent {\em The Instantiation Constraint}: if proposition $p_1$ is an instance of proposition $p_2$ then $from(p_1)$ must be an instance of $from(p_2)$, $to(p_1)$ must be an instance of $to(p_2)$ and $when(p_1)$ must overlap $when(p_2)$. \begin{quote} $(\forall p_1,p_2/Proposition)(\forall t_1/Time) (instanceOf(p_1,p_2,t_1) \then$ \\ $(\exists t_2,t_3) (in(from(p_1), from(p_2), t_2) \myand in(to(p_1), to(p_2), t_3) \myand $ \\ $during(t_1,t_2) \myand during (t_1,t_3) \myand overlaps(when(p_1),when(p_2))))$ \end{quote} \subsection{Integrity Constraints and Deductive Rules} \label{sec:formal-rules} Integrity constraints and deductive rules are mapped into closed statements in the language $\cal L$. This mapping provides the semantics for the terms of the assertion language in Telos. As an example, the following is the $\cal L$ statement corresponding to the deductive rule from section \ref{sec:rules} \begin{quote} $ (\forall t/Time)(\forall x,y,z,w/Proposition)\\ (in(x,Paper,t) \And in(y,Address,t) \And author(x,w,t) \And\\ address(w,z,t) \then replyAddress(x,z,t)) $ \end{quote} where, in turn, a predicate such as $author(x,y,t)$ corresponds to \[ (\exists p,l,t'/Proposition) (in(p,author,t') \And prop(p,x,l,y,t)). \] To make their processing tractable, rules are restricted to a ``Horn'' form: $\tt \then $. The antecedent must be a conjunction of atomic formulas while the consequent must be a single positive atomic formula. In addition, all the variables in the rule must be universally quantified at the beginning of the formula. Deductive rules are statements which are added to the appropriate historical theories and are used by $ASK$ for answering queries with respect to these theories. However, integrity constraints are statements which must be {\em satisfied}: an integrity constraint is satisfied if it is consistent with the completion of the corresponding historical theory\footnote{The completion of a knowledge base $KB$, denoted by $\overline{KB}$, is defined in the next section.}. Otherwise, we say that the constraint is {\em violated}. \subsection{A Functional Specification of the Telos System} \label{sec:functional-specification} A Telos knowledge base is characterized in terms of two sets $KB$ and $IC$. These sets are sequences of (historical) theories indexed by belief time intervals. As we mentioned earlier, each theory in $KB$ corresponds to the beliefs of the system during the time period which is the index of the theory. The time periods are demarcated by the system clock time, and therefore form a contiguous sequence up to the present time, $Now$. These beliefs are constrained by a theory in $IC$ (with identical index). Knowledge bases are modified and queried by the functions $TELL, UNTELL, RETELL$ and $ASK$. Only $TELL$ and $ASK$ are presented here. The $TELL$ operation has the functionality: \[ TELL:\ KB\ \times\ IC\ \times\ O\ \times\ Time \longrightarrow \ KB\ \times\ IC \] In addition to the objects being defined ($O$), $TELL$ looks at the last theory in the input knowledge base, say $KB_n$ (where $n$ has the form $[t,+\infty)$), the corresponding set of integrity constraints $IC_n$, the current system time, and produces a new knowledge base where the index of $KB_n$ and $IC_n$ has been changed to $[t,s)$, and a new theory $KB_{[s,+\infty)}$ and an enhanced set of integrity constraints $IC_{[s,+\infty)}$ have been added. The new theories are produced by unioning $KB_n$ (resp. $IC_n$) with atomic formulas and deductive rules (resp. integrity constraints) corresponding to the definitions in $O$. The $TELL$ operation takes effect only if the theories in $KB_{[s,+\infty)}$ and $IC_{[s,+\infty)}$ are consistent and if all the integrity constraints in $IC_{[s,+\infty)}$ are satisfied. Note that because we are in first order logic, the definition of classes resembling Russel's paradox (``all classes not members of themselves'') simply leads to an inconsistent knowledge base. Users of Telos are therefore urged to abide by the convention that only propositions at adjacent levels of the instantiation hierarchy should be related by the predicate $in$. $ASK$ can be functionally understood as follows: \[ ASK:\ KB\ \times\ Query\ \times\ Time \longrightarrow \ Answers \] $ASK$ operates on the historical theories in $KB$ whose index overlaps the time period stated in the {\tt BELIEVED} clause of the query. Assume that there is exactly one such historical theory\footnote{In the more general case, intersect the answers to the subqueries to each historical theory.}. We first need to know the {\em completion} of that historical theory. The completion of a given theory is computed using the following assumptions, inspired by \cite{Reiter84}: \begin{enumerate} \item A ``domain closure assumption'', which states that the individuals known are all the ones that exist, excluding time constants: \[ (\forall x/Proposition) \neg Time(x) \then (x=c_1 \Or x=c_2 \Or \ldots \Or x=c_n). \] A separate domain comprehension axiom is given for time intervals. \item The equality axioms (reflexivity, commutativity, associativity and Leibnitz's principle of substitution of equal terms). \item The ``unique names assumption'', asserting that distinct constants are not equal. Note that this is not asserted for temporal terms other than the ones representing standard intervals, because in general two time intervals $a$ and $b$ are assumed to be equal if and only if $equals(a,b)$ is derivable. \item The ``completed theory assumption'': to obtain negative information, we want to assume that any facts about the base predicates $isa, in, prop$ that cannot be derived from told facts or deductive rules are false. For this purpose we use the restricted form of the deductive rules to adopt a ``predicate completion'' technique such as considered in \cite{Reiter84}. \end{enumerate} Now if $query$ is a closed historical query, i.e., it is of the form $ <| W>$ (where $W$ is a first order statement) then \[ ASK(KB_n, query)= \left\{ \begin{array}{ll} yes & \mbox{{\rm if} $\overline{KB_n} \models W$}\\ no & \mbox{{\rm if} $\overline{KB_n} \models \lnot W$}\\ unknown & \mbox{{\rm if} $\overline{KB_n} \not\models W$}\\ & \mbox{ {\rm and} $\overline{KB_n} \not\models \lnot W$ }\\ \end{array} \right. \] If $query$ is an open historical query i.e., it is of the form $< x_1/\tau_1, \cdots , x_n/\tau_n\ |\ W >$ (where $W$ is a first order formula whose only free variables are $x_1,\ldots,x_n$) then \[ ASK(KB_n, query)= \left\{ \begin{array}{ll} \theta & \mbox{\rm if for every substitution $ \theta_i \in \theta$, $\overline{KB_n} \models W\theta_i$} \\ \emptyset & \mbox{\rm if there is no substitution $ \theta$ such that $\overline{KB_n} \models W\theta$} \\ \end{array} \right. \] \subsection{Formalizing the Holds Relation for $\cal L$} \label{sec:formal-prove} We provide here a brief formal account of the {\tt Holds} predicate introduced in section \ref{sec:holds}.\footnote{We are indebted to Jim des Rivieres for clarifications.} The predicate was introduced to allow meta-atributes to impose additional constraints on the free variables {\tt Obj} and {\tt HTime}, which occur in formulas that will act as preconditions, activation conditions, etc. These formulas must therefore be objects -- they will appear as parts of propositions after all -- and some form of ``quotation'' mechanism is needed for this purpose. However, once values from the actual domain of discourse (propositions, times) are substituted for {\tt Obj} and {\tt HTime}, we want the formulas to be ``unquoted'' and verified. For this purpose we encode formulas in the base language $\cal L$ as abstract syntax trees (Prolog terms or Lisp lists in prefix notation), assuming that for every logical and non-logical symbol of $\cal L$ we have a corresponding constructor. Thus $(\forall x)(P(x) \And Q(x))$ might be encoded as \[ ALL(X, AND(PRED(P,X) , PRED(Q,X))). \] If the former is called formula $\phi$, then the latter is named $\qq{\phi}$. The result is a language $\cal L'$, in which quoted sentences from $\cal L$ are also objects. We can give these sentences assertional power by setting up a simple predicate $True$, which represents the standard model theoretic notion of truth (e.g., $True(AND(A,B))$ iff $True(A)$ and $True(B)$, while $True(PRED(P,X))$ iff $P(x)$.). Alternatively, we could define a predicate $Provable$, which fomalizes some proof theory of the logic of $\cal L$ (as in \cite{Bowen-Kowalski82}). Note that the special variables {\tt Obj} and {\tt HTime} will not be quoted inside a formula, so that quantifiers outside {\tt Holds} can keep them in their scope. As shown in \cite{desRivieres-Levesque86}, one avoids the paradoxes usually associated with this sort of encoding, by the simple expedient of not allowing {\em all} formulas from $\cal L'$ to be encoded in $\cal L'$, but only those in $\cal L$. We will want users to write formulas involving {\tt Holds}, as illustrated by the case of {\tt PreCondition}. Such formulas are however not needed as arguments to $True$, so we will simply disallow them in that position, e.g., by defining \begin{center} $Holds(\qq{\phi}) \iffi NoNesting(\qq{\phi}) \And True(\qq{\phi})$ \end{center} Finally, for this construction to work properly it is necessary to have a canonical name (primitive or constructed) for every value in the domain of $\cal L$ -- every value over which one can quantify. This is not an issue for propositions, of which there is only a finite number. But time intervals have been axiomatized according to \cite{Allen-Hayes85}, so we need some naming scheme for a countable space of ``canonical intervals''. This can be accomplished, for example, by naming intervals with pairs of integers. The actual intervals which appear in propositions are then existentially quantified, and can be treated proof-theoretically according to the technique of \cite{Reiter84}: as constants for which the ``unique name axiom'' does not hold. This allows us to learn more information about them, including the fact that some intervals are equal. \section{Related Work} Telos is fundamentally a knowledge representation language, albeit one that has been specially crafted to facilitate the description of concepts related to the development of information systems. Thus, it is reasonable to look for related work in three general areas: Artificial Intelligence, Databases and Software Engineering. In each case we will concentrate on closely related approaches and influences rather than attempt to survey entire subareas. Telos is a language in the tradition of semantic networks. Its distinguishing marks over other proposals is the treatment of attributes as first-class objects, including the device of attribute instantiation, the {\em integrated} representation of temporal knowledge, and the parsimonious foundation of the language resting on the single notion of ``{\em proposition}''. %%%%%%%%% took out. Manolis \comment{Telos also uses a very simple form of default reasoning with respect to belief time in order to allow beliefs to ``persist''. Similar persistency axioms with respect to transaction time appear in \cite{Snodgrass87} and \cite{Sripada88}\footnote{Axioms for persistency with respect to history time are given in in \cite{Kowalski-Sergot86}.}.} The treatment of attributes was influenced by \cite{Kramer80} where ``slots'' are distinguished from ``metaslots'', analogously to attribute classes and metaclasses. Telos' treatment of attributes can be considered a generalization of this earlier effort. Our choice of a temporal model based on intervals, rather than time points has been influenced by \cite{Allen83} and \cite{Vilain-Kautz-vanBeek89}. Of course, the nature of the temporal component of Telos was considerably complicated by all other features that need to coexist within one linguistic and conceptual framework: notationally (making sure that time does not get in the way as the user {\tt ASK}s and {\tt TELL}s), semantically (the meaning of history and belief times), and structurally (offering time as a fourth dimension of knowledge organization in Telos) and, finally, from an implementation viewpoint. To our knowledge, no full-fledged knowledge representation language provides facilities for time that are as tightly integrated into the overall representational framework. Finally, the integration of structural/organizational aspects of knowledge representation with assertional/deductive parts, has been advocated and implemented in various forms in precursor systems such as Omega \cite{Attardi-Simi81}, Cake \cite{Rich82} and Krypton \cite{Brachman-Fikes-Levesque83}. These, and other so-called ``hybrid'' systems, combine one or more special-purpose but efficient reasoners with a general deductive mechanism in order to achieve better performance. For example, Krypton's terminologic component provides efficient reasoning about concept definitions, which are then used by the assertional component for theorem proving. Telos does not explicitly demarcate subsystems of different kinds; in fact, Telos uses the object-centered nature of the representation mechanism to structure the entire knowledge base, by making individuals and concepts be syntactic anchors for both generic and specific facts, including formulas in the logical assertion language. On the other hand, reasoning with time has been treated in a special way both in the language semantics and implementation, and the distinction between constraints/rules and ask/retrieve point to the existence of distinct ways of using what would otherwise be first-order formulas. Turning to Databases, the modeling of the application world has been the focus of much work on semantic data models \cite{Hull-King87}. Telos continues in the spirit of this work by emphasizing the importance of structuring mechanisms, including generalization, aggregation and classification, which were first identified in the context of data modeling. In fact, Telos goes further by applying these ideas uniformly to attributes as well as individuals. The equal treatment of individuals and relationships dates back to the Entity-Relationship model \cite{Chen76}, but there are many differences between Telos and ER languages, including the presence of higher order (``meta'') classes, and the absence of n-ary relationships with built-in cardinality restrictions. The addition of a temporal dimension is a further step in the evolution of conceptual models. The distinction between the ``clock'' of the application world and that of the system administrators has also been made in the work on temporal databases \cite{Snodgrass87}. Object-oriented databases \cite{Dittrich88} are a recent development, which merge the semantic modeling constructs with the notion of objects having an encapsulated internal state. They are particularly useful for CAD applications, including providing database support for Software Engineering. For example, the Cactis system \cite{Hudson-King89} concentrates on the efficient management of derived data --- objects can have local attributes defined by functional formulas, and, interestingly, separates the definition of binary relationship classes from that of the object classes being related. This is used to allow increased flexibility in making changes in the schema, and resembles Telos' view of class/individual definitions as being nothing but convenient collections of propositions, rather than monolithic wholes. The Telos implementation has not paid the same careful attention to efficiency of updates, but on the other hand it does support temporal reasoning, a full instance-of hierarchy, and allows attributes as first class citizens. Interestingly enough, the database logic F-logic \cite{Kifer-Lausen89} also treats individuals and attributes in a uniform way. Like Telos, it can express meta-queries such as ``retrieve the set of all objects which represent the labels defined for a certain object''. However, it does not support time and does not offer an instantiation dimension (instead, it treats classes and instances as members of the same lattice ordered by the ``definedness'' ordering of denotational semantics). On the other hand, F-logic offers a more explicit notion of complex objects and a nice way of dealing with inconsistencies. The inferential aspects of Telos, especially the distinction between integrity rules and deductive rules had been made by researchers in the field of Deductive Databases \cite{Gallaire-Minker-Nicolas-survey}. However, Telos' assertion language is different from the FOL-based languages usually offered in deductive databases, and the propositional 4-tuple foundations of Telos are fully novel. The functional constructs in our assertion language are reminiscent of similar constructs in the language COL \cite{Abiteboul-Grumbach88} if the temporal arguments are omitted. Requirements modeling in Software Engineering is a third research area that has influenced the development of Telos. Following the pioneering work of \cite{Balzer-Goldman79}, \cite{Bubenko80} and \cite{Greenspan84}, a consensus seems to have emerged that a requirements model should include a description of the application domain in addition to a functional specification of the system itself, both expressed in an ``object-centered'' framework. We have already discussed in this paper the close relationship between RML \cite{Greenspan84} and Telos, while \cite{Borgida-Greenspan-Mylopoulos85} discusses the relationship between RML and the work of \cite{Balzer-Goldman79} and \cite{Bubenko80}. In addition to RML, the ERAE method \cite{Hagelstein88} also considers a formal embedding of the temporal dimension into the requirements model, albeit using a temporal logic approach. Both ERAE and PLEXSYS \cite{Kotteman-Konsynski84} consider the embedding of the system in its ``usage world'' but neither permits the qualification of the ``rep(resents)'' relationship which is possible in Telos. More generally, the work on {\em domain modeling} for software reuse that began with \cite{Neighbors89} has recently produced a number of languages and systems which are intended to capture a wide range of information about software subdomains. A number of these systems, including the Lassie software information system \cite{Devambu-Selfridge-Ballard-Brachman89}, and the Desire/Rose design recovery/reuse system \cite{Biggerstaff-Perlis89} are built around languages which are explicitly based on AI knowledge representation techniques, such as frame systems and connectionist networks. There is an entire subfield of formal software specifications, and some approaches are in fact related to Knowledge Representation schemes (e.g., the Plan Calculus \cite{Rich82}). However, these schemes are usually oriented towards the description of software components, and do not attempt to address world modeling, nor the representation of software development knowledge. \section{Summary} The development, use and maintenance of information systems involves a great deal of knowledge. We have classified this knowledge as concerning (at least) four distinct domains of discourse: \begin{itemize} \item the subject world, about which information will be stored in the information system; \item the usage world, consisting of the environment within which the information system will eventually function; \item the system world, of the various incarnations of the information system itself, ranging from non-procedural requirements specifications to code; and \item the development world, of teams, development processes, design goals, schedules and decisions. \end{itemize} The knowledge involved is both generic -- the kind one learns in courses at school -- and specific -- having to do with a particular system. Moreover, it is essential for the development process to accumulate information concerning the {\em relationship} between the above four worlds. It seems intuitively clear that the ability to explicitly capture and manipulate these kinds of knowledge can be helpful for many software engineering tasks (including requirements acquisition, expert support for development, maintenance and staff training), and provides the basis for a variety of computer tools to support these activities. These expectations have been confirmed by our experience in the DAIDA project. To support the above paradigm of knowledge-intensive software development, we need knowledge bases. This paper has shown how Telos can be used to build {\em meta-models} of the various subworlds and software engineering activities involved in developing an information system, and to populate these metamodels with specifications of particular software environments and development projects. Telos is an object-centered language which has a number of special features that have enhanced its utility for maintaining a software knowledge base: \begin{itemize} \item it supports the organization of knowledge built up from ``atomic facts'' through the use of classification and generalization hierarchies; \item it is relatively easy to extend and customize with abbreviations by providing higher-order classes, including attribute meta-classes; the syntax of ``attribute categories'' and the underlying simple framework of ``propositions'' are particularly useful; \item it supports evolving views of objects and a hypertext-style browsing interface, by treating attributions as individuals; \item the consistency of the knowledge entered can be verified through constraint rules, and new values can be inferred by triggering the evaluation of rules; \item a complete ``longitudinal'' view of various domains can be captured because of the powerful yet tractable model of time which has been tightly integrated into the language; \item the evolution of the knowledge base can be recorded through the use of ``belief'' times associated with facts, and this can be used to support software maintenance; \end{itemize} There have been three prototype implementations of the language, all in PROLOG, carried out at the University of Crete \cite{Topaloglou-Koubarakis89}, the University of Passau \cite{ConceptBase89} and SCS Hamburg \cite{Haidan-Meyer90}. In addition to the DAIDA project, the language was/is used in a number of research projects, including ESPRIT projects LOKI \cite{loki88}, ITHACA \cite{ithaca} and MULTIWORKS \cite{Hahn-Jarke-Kreplin-Farusi-Pimpinelli89}, with generally positive feedback. In a nutshell, the contribution of Telos lies in its adaptation of ideas from knowledge representation, deductive databases and requirements modeling languages in order to offer a language that can be used to tackle a broader class of modeling tasks -- arising from information system development tasks -- than those attempted by other proposals. Design records for large information systems, formally or informally represented, are bound to contain millions of facts. If the reader were to accept the thesis that we can develop language facilities that are expressively adequate for the task at hand, it would still not be possible to manage effectively such records due to the lack of suitable knowledge base management systems, e.g., ones that can manage knowledge bases with $O(1M)$ facts, offering implementation techniques for query optimization, concurrency control and recovery. Even though unavailable yet, we believe that such facilities can and will be built in the next few years and will open the way towards more systematic, effective and productive software development technologies. We also believe that the key to such new technologies is and will continue to be the availability of {\em all relevant knowledge} to {\em human} designers. \section*{Acknowledgements} We gratefully acknowledge the contribution of insightful ideas, suggestions and moral support from Sol Greenspan (GTE Laboratories, Waltham, MA) whose thesis provided a rationale and a springboard for this research; Yannis Vassiliou, Thodoros Topaloglou, Manolis Marakakis and others (Institute of Computer Science, Iraklion, Crete, Greece) for serving as first users of the language; John Gallagher and Levy Solomon (SCS Technische Automation und Systeme GmbH, Hamburg, Germany), who did the first implementation of CML; Thomas Rose, Manfred Jeusfeld and others (University of Passau, Germany) who carried out a second implementation; as well as other members of the ESPRIT projects LOKI and DAIDA. Last, but not least, we would like to thank Lawrence Chung, Brian Nixon, Martin Stanley and other members of the Taxis group at the University of Toronto for providing a friendly and stimulating research environment. \begin{thebibliography}{10} \bibitem{Abiteboul-Grumbach88} {\sc Abiteboul, S., and Grumbach, S.} \newblock {COL: a Logic-based Language for Complex Objects}. \newblock In {\em Proceedings of the International Conference on Extending Data Base Technology\/} (Venice, Italy, March 1988). \bibitem{Allen83} {\sc Allen, J.} \newblock {Maintaining Knowledge about Temporal Intervals}. \newblock {\em Communications of the {ACM} 26}, 11 (November 1983), 832--843. \bibitem{Allen-Hayes85} {\sc Allen, J., and Hayes, P.} \newblock {A Common-Sense Theory of Time}. \newblock In {\em Proceedings of the Ninth International Joint Conference on Artificial Intelligence\/} (Los Angeles, {CA}, 1985), pp.~528--531. \bibitem{Allen-Hayes89} {\sc Allen, J., and Hayes, P.} \newblock {Moments and Points In an Interval-Based Temporal Logic}. \newblock {\em {Computational Intelligence} 5\/} (November 1989), 225--238. \bibitem{Attardi-Simi81} {\sc Attardi, G., and Simi, M.} \newblock {Consistency and Completeness of OMEGA, a Logic For Knowledge Representation}. \newblock In {\em {Proceedings of IJCAI-81}\/} ({Vancouver, B.C}, 1981), pp.~504--510. \bibitem{Balzer-Goldman79} {\sc Balzer, R., and Goldman, N.} \newblock {Principles of Good Software Specification and Their Implications For Specification Languages}. \newblock In {\em {Proceedings of the Conference on Specifications for Reliable Software}\/} (Boston, MA, 1979), pp.~58--67. \bibitem{Biggerstaff-Perlis89} {\sc Biggerstaff, T., and Perlis, A.}, Eds. \newblock {\em {Software Reusability (Vol. 1 and 2)}}. \newblock {ACM Press}, 1989. \bibitem{loki88} {\sc Binot, J.-L., Demoen, B., Hanne, K.-H., Solomon, L., Vassiliou, Y., von Haan, W., and Wachtel, T.} \newblock {LOKI: A Logic Oriented Approach to Data and Knowledge Bases Supporting Natural Language Interaction}. \newblock In {\em Proceedings of the ESPRIT '88 Conference\/} (1988), North-Holland, pp.~562--577. \bibitem{Borgida-Greenspan-Mylopoulos85} {\sc Borgida, A., Greenspan, S.~J., and Mylopoulos, J.} \newblock {Knowledge Representation as the Basis to Requirements Specification}. \newblock {\em IEEE Computer 18}, 4 (1985), 82--91. \bibitem{Bowen-Kowalski82} {\sc Bowen, K., and Kowalski, R.} \newblock {Amalgamating Language and Meta-Language}. \newblock In {\em {Logic Programming}}, K.~Clark and S.~Tarnlund, Eds. Academic Press, 1982, pp.~153--172. \bibitem{Brachman-Fikes-Levesque83} {\sc Brachman, R., Fikes, R., and Levesque, H.} \newblock {KRYPTON: Integrating Terminology and Assertion}. \newblock In {\em {Proceedings of AAAI-83}\/} ({Washington, DC}, 1983), pp.~31--35. \bibitem{Brachman-Levesque85} {\sc Brachman, R.~J., and Levesque, H.~J.}, Eds. \newblock {\em Readings in Knowledge Representation}. \newblock Morgan Kaufmann, 1985. \bibitem{Brachman-Levesque86} {\sc Brachman, R.~J., and Levesque, H.~J.} \newblock {The Knowledge Level of a KBMS}. \newblock In {\em On Knowledge Base Management Systems}, M.~Brodie and J.~Mylopoulos, Eds. Springer-Verlag, 1986, pp.~9--12. \bibitem{Bubenko80} {\sc Bubenko, J.} \newblock {On Concepts and Strategies for Requirements and Information Analysis}. \newblock In {\em {Prodeedings of IFIP-80}\/} (1980). \bibitem{Chen76} {\sc Chen, P.} \newblock {The entity-relationship model-Towards a unified view of data}. \newblock {\em ACM Transcactions on Database Systems 1}, 1 (March 1976), 9--36. \bibitem{Chung89} {\sc Chung, K., Katalagarianos, P., Marakakis, M., Mertikas, M., Mylopoulos, J., and Vassiliou, Y.} \newblock {From Information System Requirements to Designs: A Mapping Framework}. \newblock {Technical Note 53, Computer Systems Research Institute, University of Toronto}, November 1989. \bibitem{Conklin-Begeman88} {\sc Conklin, J., and Begeman, M.} \newblock {A hypertext tool for exploratory policy discussion.} \newblock {\em ACM Transactions on Office Information Systems 6}, 4 (1988), 303--331. \bibitem{desRivieres-Levesque86} {\sc des Rivi{\` e}res, J., and Levesque, H.~J.} \newblock {The Consistency of Syntactical Treatments of Knowledge}. \newblock In {\em {Proceedings of the 2nd Conference on Theoretical Aspects of Reasoning About Knowledge}\/} (Los Altos, California, 1986), J.~Y. Halpern, Ed., Morgan Kaufmann Publishers, Inc., pp.~115--130. \bibitem{Devambu-Selfridge-Ballard-Brachman89} {\sc Devanbu, P., P., S., B., B., and R., B.} \newblock {A Knoweldge-Based Software Information System}. \newblock In {\em Proceedings of IJCAI-89\/} (1989), pp.~500--501. \bibitem{Dittrich88} {\sc Dittrich, K.}, Ed. \newblock {\em Advances in Object-Oriented Database Systems (Proceedings of the 2nd International Workshop on Object-Oriented Database Systems)}. \newblock {Lecture Notes in Computer Science, 334, Springer Verlag}, 1988. \bibitem{ConceptBase89} {\sc Eherer, S., Jarke, M., Jeusfeld, M., Miethsam, A., and Rose, T.} \newblock {A Global KBMS for Database Software Evolution: ConceptBase 2.0 User Manual}. \newblock Tech. Rep. MIP-8936, University of Passau, 1989. \bibitem{Frisch89} {\sc Frisch, A.} \newblock {A General Framework for Sorted Deduction: Fundamental Results on Hybrid Reasoning}. \newblock In {\em {Proceedings of 1st International Conference on Principles of Knowledge Representation and Reasoning}\/} (Toronto, Ontario, 1989), R.~Brachman, H.~Levesque, and R.~Reiter, Eds., pp.~126--136. \bibitem{Gallaire-Minker-Nicolas-survey} {\sc Gallaire, H., Minker, J., and Nicolas, J.} \newblock {Logic and Databases: A Deductive Approach}. \newblock {\em ACM Computing Surveys 15}, 2 (1984), 52--57. \bibitem{Gallaire-Nicolas89} {\sc Gallaire, H., and Nicolas, J.-M.} \newblock {How to Look at Deductive Databases}. \newblock In {\em {Foundations of Knowledge Base Management}}, J.~Schmidt and C.~Thanos, Eds. Springer Verlag, 1989, pp.~119--127. \bibitem{Greenspan84} {\sc Greenspan, S.~J.} \newblock {\em {Requirements Modelling: A Knowledge Representation Approach to Software Requirements Definition}}. \newblock PhD thesis, {Dept. of Computer Science, University of Toronto}, 1984. \bibitem{Hagelstein88} {\sc Hagelstein, J.} \newblock {Declarative approach to information systems requirements}. \newblock {\em {Knowledge-Based Systems} 1}, 4 (1988), 211--220. \bibitem{Hahn-Jarke-Kreplin-Farusi-Pimpinelli89} {\sc Hahn, U., Jarke, M., Kreplin, K., Farusi, M., and Pimpinelli, F.} \newblock {Co-AUTHOR: a hypermedia group authoring environment}. \newblock In {\em {Proceedings of the European Conference on Computer-Supported Cooperative Work}\/} ({Gatwick, United Kingdom}, 1989). \bibitem{Hahn-Jarke-Rose90} {\sc Hahn, U., Jarke, M., and T., R.} \newblock {Group Work in Software Projects}. \newblock In {\em {Proc. IFIP WG 8.4 Conference on Multi-User Applications and Interfaces}\/} ({Iraklion, Crete, Greece}, September 1990). \bibitem{Haidan-Meyer90} {\sc Haidan, R., and Meyer, R.} \newblock {Requirements Modeling and System Specification In a Logic-Based Knowledge Representation Framework}. \newblock {Technical Report, ESPRIT project 892 (DAIDA), SCS Informationstechnik, Hamburg, Germany}, 1990. \bibitem{Hudson-King89} {\sc Hudson, S., and King, R.} \newblock {Cactis: A Self-adaptive, Concurrent Implementation of an Object-Oriented Database Management System}. \newblock {\em ACM Transactions on Database Systems 14}, 3 (1989), 291--321. \bibitem{Hull-King87} {\sc Hull, R., and King, R.} \newblock {Semantic Database Modelling: Survey, Applications and Research Issues}. \newblock {\em ACM Computing Surveys 19}, 3 (1987), 201--260. \bibitem{Jarke-Jeusfeld-Rose89} {\sc Jarke, M., Jeusfeld, M., and Rose, T.} \newblock {Software Process Modeling as a Strategy for KBMS Implementation}. \newblock In {\em {Proceedings of the First Internatinal Conference on Deductive and Object-Oriented Databases}\/} ({Kyoto, Japan}, 1989), pp.~496--512. \bibitem{Jarke-Jeusfeld-Rose90} {\sc Jarke, M., Jeusfeld, M., and Rose, T.} \newblock {A software process data model for knowledge engineering in information systems}. \newblock {\em Information Systems 15}, 1 (1990), 86--115. \bibitem{Jarke-Mylopoulos-Schmidt-Vassiliou90} {\sc Jarke, M., Mylopoulos, J., Schmidt, J., and Vassiliou, Y.} \newblock {Information Systems Development as Knowledge Engineering: the DAIDA Project}. \newblock {Technical Report, ESPRIT project 892 (DAIDA), Forthcoming}. \bibitem{Kifer-Lausen89} {\sc Kifer, M., and Lausen, G.} \newblock {F-Logic: A Higher-Order Language for Reasoning about Objects, Inheritance, and Scheme}. \newblock In {\em {Proceedings of ACM SIGMOD International Conference on Management of Data}\/} (1989), pp.~134--146. \bibitem{Kotteman-Konsynski84} {\sc Konsysnki, B., and Kotteman, J.} \newblock {Dynamic Metasystems for Information Systems Development}. \newblock In {\em {Prodeedings of 5th International Conference on Information Systems}\/} (1984), pp.~187--204. \bibitem{Koubarakis-Mylopoulos-Stanley-Borgida89} {\sc Koubarakis, M., Mylopoulos, J., Stanley, M., and Borgida, A.} \newblock {Telos: Features and Formalization}. \newblock Tech. Rep. {KRR-TR-89-4}, {Dept. of Computer Science, University of Toronto}, 1989. \bibitem{Kramer80} {\sc Kramer, B.} \newblock The representation of programs in the procedural semantic network formalism. \newblock Master's thesis, Dept. of Computer Science, University of Toronto, 1980. \bibitem{Mylopoulos-Bernstein-Wong80} {\sc Mylopoulos, J., Bernstein, P.~A., and Wong, H.~K.} \newblock {A Language Facility for Designing Interactive Data-intensive Applications}. \newblock {\em ACM Transactions on Database Systems 5}, 2 (1980), 185--207. \bibitem{Mylopoulos-Borgida-Jarke-Koubarakis90} {\sc Mylopoulos, J., Borgida, A., Jarke, M., and Koubarakis, M.} \newblock {Telos: A Language for Representing Knowledge About Information Systems}. \newblock Tech. Rep. {KRR-TR-89-1 (Revised)}, {Dept. of Computer Science, University of Toronto}, August 1990. \bibitem{Neighbors89} {\sc Neighbors, J.} \newblock {Draco: A Method for Engineering Reusable Software Systems}. \newblock In {\em {Software Reusability}}, T.~Biggerstaff and A.~Perlis, Eds., vol.~1. {ACM Press}, 1989, pp.~295--319. \bibitem{Olle-Sol-VerjinStuart82} {\sc Olle, T., Sol, H., and A.A., V.-S.}, Eds. \newblock {\em {Information Systems Design Methodologies: A Comparative Review}}. \newblock {North Holland}, 1982. \bibitem{Pernici89} {\sc Pernici, B.} \newblock {Objects with Roles}. \newblock In {\em {Object-Oriented Development}}, D.~Tsichritzis, Ed. {Centre Universitaire d'Informatique, Universite de Geneve, Switzerland}, 1989, pp.~75--100. \bibitem{ithaca} {\sc Profrock, A.-K., Ader, M., Muller, G., and Tsichritzis, D.} \newblock {ITHACA: An Overview}. \newblock Tech. rep., {Nixdorf Software Engineering GmbH, Berlin}, 1989. \bibitem{Reiter84} {\sc Reiter, R.} \newblock Towards a logical reconstruction of relational database theory. \newblock In {\em On Conceptual Modelling: Perspectives from Artificial Intelligence, Databases and Programming Languages}, M.~Brodie, J.~Mylopoulos, and J.~Schmidt, Eds. Springer Verlag, 1984, pp.~191--233. \bibitem{Rich82} {\sc Rich, C.} \newblock {Knowledge Representation Languages and Predicate Calculus: How to Have Your Cake and Eat it Too}. \newblock In {\em {Proceedings of AAAI-82}\/} ({Pittsburgh}, 1982). \bibitem{Rich-Waters86} {\sc Rich, C., and Waters, R.}, Eds. \newblock {\em {Artificial Intelligence and Software Engineering}}. \newblock {Morgan Kaufmann}, 1986. \bibitem{Rose-Jarke90} {\sc Rose, T., and Jarke, M.} \newblock {A Decision-Based Configuration Process Model}. \newblock In {\em {Proceedings of 12th International Conference on Software Engineering}\/} ({Nice, France}, 1990). \bibitem{Ross-Schoman77} {\sc Ross, D., and Schoman, K.} \newblock {Structured Analysis for Requirements Definition}. \newblock {\em IEEE Transactions on Software Engineering\/} (1977), 49--60. \bibitem{Snodgrass87} {\sc Snodgrass, R.} \newblock {The Temporal Query Language TQuel}. \newblock {\em ACM Transcactions on Database Systems 12}, 2 (June 1987), 247--298. \bibitem{Srikanth-Jarke89} {\sc Srinkath, R., and Jarke, M.} \newblock {The design of knowledge-based systems for managing ill-structured software projects}. \newblock {\em Decision Support Systems 5}, 4 (1989), 425--447. \bibitem{Stanley86} {\sc Stanley, M.} \newblock {CML}: A knowledge representation language with application to requirements modelling. \newblock Master's thesis, Dept. of Computer Science, University of Toronto, 1986. \bibitem{Topaloglou-Koubarakis89} {\sc Topaloglou, T., and Koubarakis, M.} \newblock {Implementation of Telos: Problems and Solutions}. \newblock Tech. Rep. {KRR-TR-89-8}, {Dept. of Computer Science, University of Toronto}, 1989. \bibitem{Toulmin58} {\sc Toulmin, S.} \newblock {\em {The Uses of Argument}}. \newblock {Cambridge University Press}, 1958. \bibitem{Vilain-Kautz-vanBeek89} {\sc Vilain, M., Kautz, H., and van Beek, P.} \newblock {Constraint Propagation Algorithms for Temporal Reasoning: a Revised Report}. \newblock In {\em {Readings in Qualitative Reasoning about Physical Systems}}, D.~Weld and J.~de~Kleer, Eds. {Morgan Kaufmann}, 1989, pp.~373--381. \bibitem{Winograd-Flores87} {\sc Winograd, T., and Flores, F.} \newblock {\em {Understanding Computers and Cognition}}. \newblock {Ablex Corporation}, 1987. \end{thebibliography} \end{document}