Viewpoint

Analysis: Study

A Case

Julio Cesar S. P. Leite Departamento de InformAtica Pontifkia Universidade Catblica do Rio de Janeiro R. Marquis de S. Vicente 225 Rio de Janeiro 22453 BraGl results help to show that comparing different perceptions about a problem helps the understanding of the problem Abstract being addressed. Requirements modeling demands that the knowlThe study presented here is very similar to the study edge of what should be modeled be available. Acdone by Wing (161 on the twelve articles addressing the quiring this knowledge or eliciting the necessary relibrary problem presented at the fourth IWWSD. Wing quirements ia recognized to be a very hard problem. compares the different approaches and how they reveal Different enggestione have been made to alleviate problems in the description of the library example. Wings this problem. We examine the application of one comparison produced a list of problems of ambiguities such approach, viewpoint resolution, towards the IWSSD library problem. This approach ie baeed on and incompletenesses of the library description. She the idea of very early validation. The case study correctly pointed out that: the interesting result of the presented help8 justify the claim that early validaspecification exercise is not the specification itself by the tion is a desirable characteristic of the software coninsight gained about the specificand. From our viewpoint, etruction process. Four different view8 of the library Wing performed a viewpoint resolution over the 12 cases problem are analyzed by an automated sndyzer, analyzed. In our study, we show how our viewpoint resowhich is capable of identifying problem8 of correctlution framework is applied to the same problem analyzed ness and completeness in a psir of views. The reby Wing. sults obtained, besides showing the benefits of early validstion, show how viewpoint resolution can help In the next sections, we will present the overall undervery early validation. standing of viewpoint resolution, the cases analyzed, the results of the study, and conclusions based on these results.

Introduction

Viewpoint resolution was proposed by Leite [9] as a means for very early validation in the process of requirements elicitation. Requirements elicitation is the process in requirements analysis responsible for understanding, finding and gathering information. As a part of requirements elicitation, the objective of fact-validation is to make sure that the facts gathered reflect the original intent, as well as to help unfold the knowledge not yet recorded as facts. Viewpoint resolution is a different approach to very early validation. It takes place in the process of factvalidation, and it is based on the acknowledgement that software requirements can be elicited from different viewpoints. Our objective is to show, using a seemingly simple problem description, how a early validation scheme, based on viewpoints, is capable of identifying and classifying problems related to correctness and completeness. Our
Permission to copy without fee all or part of this material is granted Its date appear, and notice IS given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specdc permission.
provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and

Why

Viewpoints?

In the task of modeling the users expectations in the universe of discourse, a systems analyst may encounter, and usually does, different opinions about the problem being addressed. Different systems analysts, when modeling the users expectation in the same universe of discourse, produce different models. The same systems analyst when modeling the same universe of discourse may do so by using different perspectives (e.g.., a data model versus a process model). All the above is common knowledge. The important point is that some software engineering methods use this fact with the objective of producing a model that better mirrors the users expectations in the universe of discourse.
A fact is a relationship vocabulary between keywords of the application

%hirerse of di8COUnC ir the ererd context in which the roftrarc will be developed. The unirerse of discourse includes alI the BOUIKCB of information and all the people related to the software. These people are referred to 81 the actor-n in this universe of discourse.

Ill
01989 ACM 0-89791-3051/89/0500/0111$00.75

An example of such a method is CORE [lo]. The principle that more sources of information provide a better understanding of a subject has been used for centuries in court investigation. Different witnesses may have conflicting or complementary recollections. By using this principle in the process of elicitation, the chances of detecting correctness and completeness problems will be greater. To effectively profit from this principle it is necessary to compare and analyze different views. The analysis and comparison of viewpoints as proposed by Ross SADT [13] and Mullerys CORE are informal tasks. They are similar to what we [Q] call Using Informal Checking. They rely heavily on the good systems analyst. Although CORE and SADT advocate the use of viewpoints, neither one has a structured model to explicitly state how to profit from doing so. That is, besides the reliance on inspection procedures and some general guidelines, no model is presented for the use of viewpoints with the results derived from their inspection. In order to properly profit from considering different viewpoints, there is a need for what we call viewpoint re.+ olution. Next, we describe viewpoint resolution and define the terminology used in this framework.

RequirementsAnalysis

Modeling

Repnrenlobon Orwanwotion

Fact-ralidatron Figure 1: Parts of the Requirements Analysis Process Viewpoint resolution is the process which identifies discrepancies between two different viewpoints, classifies and evaluates those discrep ancies and integrates the alternative solutions into a single representation (Figure 2). By examining the model presented in Figure 2 and the definition of requirements analysis (Figure l), it is easy to note that there are some viewpoint resolution tasks beand others belonging to commalonging to fact-validation nication. The tasks related to fact-validation are called viewpoint analysis and the tasks related to communication are called viewpoint reconciliation. Our work [Q] does not deal, in detail, with viewpoint reconciliation. Our work has focused on the problems of identification oi discrepancies and the classification of these discrepancies, thus providing an agenda upon which the evaluation and integration of viewpoints can be based. In the next section we present the overall strategy for identification and classification of discrepancies in viewpoint resolution. The terms and their definitions used thereafter in the text course - Universe of which the software will course includes all the are as follows. Universe of disdiscourse is the overall context in be developed. The universe of dig sources of information and all the

Viewpoint

Resolution

Viewpoint resolution is a means for very early validation in the process of requirements elicitation. It assumes a process oriented definition of requirements analysis as proposed in [2]. According to this definition, requirements analysis is seen as composed of two processes: requirements elicitation and modeling (see Figure 1).

flikrenccs

FACT-VALIDATION

alternative

COMMUNICATlOh I solution

Figure 2: Viewpoint Resolution

112

people related to the software. These people are referred to aa the actors in this universe of discourse. Viewpoint - A viewpoint is a standing or mental position used by an individual when examining or observing a universe of discourse. A viewpoint is identified by an individual (e.g., his name) and hi role in the universe of discourse (e.g., a systems analyst, programmer, or manager). Perspective - A perspective is a set of facts observed and modeled according to a particular modeling aspect of reality and a viewpoint. An example of such a particular modeling aspect is what is known as data modeling. In our method we use three modeling aspects: the data perspective, the actor perspective, and the process perspective. View - A view is an integration of perspectives. This integration is achieved by a view-construction process. l3ierarchies The is-a hierarchy of concepts in the universe of discourse and the parts-of hierarchy of concepts in the universe of discourse.

two rule bases, each one representing a different view or perspective according to a viewpoint. The process of validating facts is dependent on the pr+ cess of finding facts. It is assumed that the facts (keywords) are available before the application of the viewpoint resolution strategy. Next we present the overall method behind producing a viewpoint, the description of the VWPl, and an overall description of the procedures that analyze different viewpoints.

4.1

Method

Proposed Analysis

Strategy

for Viewpoint

The proposed strategy comprises procedures to formalize viewpoints (method), procedures to analyze the formalized viewpoints (static analyzer), and a special language, VWPI, to represent viewpoints. The language provides the representation which registers the formalism, and makes possible its analysis The language is derived from PRISM (51, a production system architecture. As such, our viewpoint analysis strategy is basically a process for finding discrepancies between

In Figure 3 there is an overall description of the strategy. John and Mary, both systems analysts, perform the task of modeling users intentions. They both use the VWPl language to express their perception of the universe of dig course. They use different perspectives (process, data, and actor) and different hierarchies (is-a, and partsof) to improve their own view. Once a series of critiques is provided, each analyst alone, solves the internal conflicts and integrates their final perception into a view. This final view is expressed in the process perspective together with the hierarchies. After that, both viewpoints are compared and analyzed. Thus, in order to identify and classify discrepancies between different viewpoints, views are to be taken from the viewpoints. Views are produced by a process called view construction. The construction of a view is based on the following.
l

A fact-finding

method is defined,

Figure 3: The Proposed Strategy

113

. a viewpoint holder with a specific role in the universe of discourse,3 uses different perspectives and hierarchies in modeling his viewpoints,
l

perspectives and hierarchies are analyzed by a static analyzer, and a view is a model integrating the different perspectives and hierarchies taken from the same viewpoint.

process perspective and hierarchies which are then considered to be the representation of his viewpoint about the problem. The general guidelines for acquiring hierarchies and perspectives are as follows. Provide is-a and partsof hierarchies for the concepts presented in the universe of discourse. For each perspective
l

find the facts; express the facts using keywords of the application de main;
classify the facts into: agents facts; and objects facts, actions facts, and

After two views are available it is possible to compare different viewpoints. As noted above, it is common knowledge that, systems analysts, when modeling the universe of discourse, may do so by using different perspectives. An example is the usual modeling of data and processes. This work, in addition to data and process modeling, uses actor modeling [q. The idea behind actor modeling is to model using the perspective of those who are responsible for the processes, i.e., human agents or devices. The objective of using hierarchies is to try to attach some semantics to the information encoded on the viewpoint language. A specialization relationship between keywords is established as well as a decomposition relationship. In order to COIBtNCt a view a systems analyst describes the problem using the three perspectives and two hierarchies. The perspectives are: the actor perspective, the data perspective, and the process perspective. The hierarchies are the is-a hierarchy and the parts-of hierarchy. The perspectives and hierarchies are compared, and the list of discrepancies and types of discrepancies are produced. A view is the integration of perspectives and hierarchies, achieved by the viewpoint holder, with the help of an agenda, which is produced by the analysis of perspectives. When no more feedback is available from the analysis of perspectives, then an integration can occur. The construction of a perspective is a process in which there is the assumption that the systems analys,t uses the concept of application vocabulary [2], such that the keywords of the universe of discourse are carried into the viewpoint representation. The basic idea is that a systems analyst first analyzes a problem and writes down his findings using the VWPl actor perspective. Sometime later, without looking at the result of the actor perspective, the analyst does the same using the data perspective and the process perspective. The same approach is used in acquiring the hierarchies. It is assumed that the comparison of those perspectives and hierarchies held by the same systems analyst will provide him with clues to produce a better
%ur work used a fixed role of the viewpoint holder, that is the role of a systemsana1.W. It is important to note that in the conetruction of a view there is no need for the tanks related to the communication process (see Fii 2). Site the dkrcpancies in view construction art rclsted to a 8i@e person, the systemsanalyst, the mapping of solution to vierrpoints and the negotiation are not l problem, since they only depend on one single individual.

define functionality of facts by coding them as productions.

Objects represent both the objects and the rtater of these objects (that is, objects are the facts that could not be classified under action or agent). There are no constraints on providing the hierarchies; an item is chosen to be in the hierarchy by the sole judgement of the viewpoint holder. The guidelines are purposely loose to make it simpler for the viewpoint holder to express his views. In order to use the method as described above a rep resentation in which this information will be cast is necessary. The description of such representation is given below. 4.2

The

Viewpoint

Language

A language was created for representing viewpoints, and its syntax and semantics were defined. This language is derived from PRISM [5], a production system architecture. As such our viewpoint resolution strategy is basically a process for finding discrepancies between two rule bases, each one representing a different perspective or viewpoint. This representations main objective is to register early results of the fact-elicitation process in the requirements elicitation effort. It is not intended to be a requirements language. Its usefulness is restricted to the fact-validation process. Our research has been exploring the use of a rule base language as a way of expressing functionality and constraints for the process of elicitation in requirements analysis. A claim made earlier [a] and the empirical evidence available from our work [a], together with references from the literature [4], allows us to hypothesize that expressing functionality and functionality-related constraints in production rules is simple and fairly easy to use. The overall idea of VWPl is to have a predefined structure for the construction of rules. The imposition of a further constraint on the usual scheme of the left hand side being conditions and the right hand side being actions, makes it possible that some static semantic information is made available by the rule structure itself. The approach used in VWPl is similar to the one used in case gmmmorr

114

[ll], where the structures produced by the grammar rules correspond to semantics relations rather than to strictly syntactic ones. In the case of VWPl the semantics relations are achieved by using what we call typer and C~UJJCJ constraints. Types are the differents sorts of facts used, that is, the object facts, the action f&b, and the agent facts. Classes are the dilferent roles each fact may have in a rule. In a rule a fact can:
l

is enough similarity between them. In our case there is a series of factors that leads to that similtitg; below we list the most important ones.
l

The fact that viewpoint holders are viewing the same universe of discourse. The use of a method which stress the importance of maintaining the concept of application vocabulary when modeling a view or a perspective. The use of a special language which constrains how the rules are expressed.

be deleted from working memory (we call that the input C&l II), be added to the working memory (we call that the
OUtpUt
CbJJ),

Of

remain in working memory (we call that the inwantint ChJJ).

A fad is a relationship between keywords. The keywords used for expressing facts in VWPl are checked against a type list before being parsed. In other words, a set membership semantic check is performed on the keywords provided for describing the view. The general structure of the rules are described by the VWPl grammar [9]. For each perspective there is a special combination of types and classes. In this article we only use the process perspective, for which the rule structure is (LBfollows.
l

LHS - input is an action and objects (optional), invariant can be an agent and/or an object. RI-IS - output is an object.

A fact is composed of a fad-keyword and fad-attribrh?. An example is (book =book-id =author =title). In this case we have the fact-keyword book and the attributes: book-id, author, and title.. By using a nondeterministic control, it is possible to use the process perspective as an early, executable, expression of the requirements Ia Hierarchies are encoded as lists. The lists are organized by the kind of hierarchy (is-a, or parts-of) and the type of the facts. For each kind and type the root in the hierarchy is the head of a list followed by the leaves of that bierarchy. Next, we describe the automated static analyzer implemented in Scheme [la].
4.3

The static analyzer proposed and implemented has two major tasks: finding which rules are similar between each other, and, once rules are paired, identifying and classifying the discrepancies between them. Rules that are not paired = classified as missing information. The pairing of rules and their further analysis are basically syntactic oriented. Being based on the syntactic representation of terms, the analyzer depends basically on pattern matchers and partial matchers. Those matching procedures, which are applied between facts of the two different rule sets, have different scoring algorithms depending on the semantic information available from the lyper and C~JJCJ of each fact. The classification of discrepancies, that is, determining which are the missing information discrepancies and which are the wrong information discrepancies, is done based on scores resulting from the matchers and on the information available in the hierarchies. In designing the static analyzer we borrowed several ideas from the work on analogy in Artificial Intelligence and used a descriptive framework described by Hall [3] (Figu~ 4). Simple semantics hints, such as: using hierarchies and case grammars, are used to enhance the performance of the analyzer. It is ob vious that the static analyzer can not say anything about two rules that do not have discrepancies but which are not correct with respect to the universe of discourse.

Case Study

The Static

Analyzer

The analysis of different perspectives and different views is achieved by a set of procedures, which perform an analysis of two sets of perspectives or views. The perspectives and/or views are represented using VWPL Because VWPl is a rule based representation, the static analysis is really performed between two rule sets (Figure 4). Comparing two rule sets only makes sense when there
Working memory is the global database of a production where the facts are kept & chqed. system,

The csse study undertaken by this article is based on four articles presented at the fourth IWSSD: A Larch Specifycation of tAc Library Problem [15], WAot Dou it Meata to Say that Q Speeiculion ir Complete [l?], Toward a Reqrirementr Apprentice [12], and SXL: An Etccr~able Spccificalion Longrage f6]. Each of these articles has a different approach; Wings work uses a formal language, Yues is based on the notions of causation and conditionals in logic, Richs work is based on the notions of domain knowledge, and Lees is based on an executable language. All
There are four general heuristics used in the static analyzer: partial matching heuristics. scoring heuristics, evaluation heuristics, md classification of discrepancies heuristics (91.

elaboration heuristics
4 ELABORATE p~rs

hierarchies
-

L-e
EVALUATE discrepancies

Figure 4: The Static Analyzer Heuristics Using the above set of heuristics it was relatively straightthe papers deal with the library problem. Since we believe foward to come up with VWPl rules for each of the ap that the audience of this article is familiar with t,he library proaches. The less easy tasks were: choosing the right problem we do not describe it here. attributes in order to give the execution flavor of VWPl In order to make it possible to present in a short paper (process perspective), and describing the notion of number the details of viewpoint analysis, we restricted ourselves of books checked out to a customer. to the action check-out and on the constrai.nts of the It should be clear that some of the papers do not inlibrary problem. In [9] longer cases are reported. Next we tend to give explicit descriptions, let. alone complete ones. outline the main assumptions used in the study. as we!! Because of that, it is not fair to suppose that one approach as the heuristic used to transform each author Jescriptiol: is more complete or more correct than the others. On the into a view other hand, since some of the approaches were less com5.1 Premises and General Heuristic plete than others, we could demonstrate the capability of The ideal case study would be to have each of the authors our automated viewpoint analysis. Next we present the describe the library problem using our viewpoint language. codified view of each author. VWPl, and using the method we prescribed. Since this is 5.2 VWPl Descriptions not the c8se, we simulated their use of VWPl. This simulation is believed to be realistic because of the following The descriptions use the perspective rule described above. assumptions. Each of the authors, independent of the ap The fact delele-ftom the working memory (RI-IS) is the preach used, performed a elicitation process. Each author pre-condition input (LHS). A pre-condition input is dis produced a model of the problem using their preferred carded in order to maintain the working memory consis approach. The universe of discourse is the Iibrary statetency. The fact add-to the working memory (RHS) is the ment, augmented by each author preconcived notion of a post-condition output. The other facts in the LHS are library. Most of the authors used the concept of applithe pre-conditions that did not change, that is, the incation vocabulary. The actions and the agents are easily variants. In the hierarchies ir-a and parts-of, the head of identified. Each author has already debuged his underthe list is the root of the hierarchy. We will provide a brief standing of the problem, such that we can consider their comment for the first rule of these descriptions, to help the representations to be their final (view of the problem. understanding of the VWPl syntax. The general heuristic used to construct each author TOE viewpoint is as follows: ( Find where the author describes the action check(21 ((check-oat =borrorer =copy) out and base the construction of the rule(sj (book =author =titlo =copy) (library-copy -copy) in that description. Use the same keyvwords, (<not> (copy-borromor =borroror =copy))) used by the definition of operations or entities --> in the author method, for naming the facts. ((Sdelste-from IR (chock-oat =borrorrr -copy)) Use as attributes of the facts the parameters (trdd-to m (copy-borrower =borrowor =copy)))) ; ml* 21 ClfECr-OUY ir tha input. BOOK, or the attributes of each operation or entity. ; LIBELBY-COPY and <IOTs COPY-BOYLBOWEIEB l ra In the approaches where there is separation be; invariants and COPY-BOBBOUEB is thw output. tween data and process, use the data portion to LT.: borromr. copy, ; The l ttribator help constructing the hierarchies. Also, use the ; author. titl. and copy. data portion to help the identification of the at(22 <(countofcopy =usar =x11 (groatrr -IL -n-minar-onr)) tributes. Distinguish agents from objects based (chockout-Unit *tmr =n-mInur-onr) on a well behaved guess; for the action there --> is no doubt, since that the process check-out ((Sadd-to wm <error checkout-limit)))) is very well distinguished in all the four works. )

116

<ir-r
(puta-of

(1 (uoor
(2

borrowor (book author

libruy-rtoff))) titlo copy)))

<book -author-of (book-railablo

-title-of)
*author-of

=titlo-of)

; ; ; ;
;

In tho ir-r hierarchy tho yout user ir tho higher generalization of borroror aud library-rtoff. In tho partr-of hierarchy; author. title aud copy are partr of thr object book.

PICE ( (51 ((check-out =irbn) (library =irbn) (staff =rtaff-nuo)) <uru -uror-rum*) --> (<$dolete-from wm (chock-out =irbn) (library =irbn)))) (52 <<chock-out =irbn) (anot> (library -irbn))) --> library)))) ((Ladd-to n (error 1 (is-a (2 (library repository) (library copies-of-books))) (partr-of (2 (repository itonr place rtaff aaorr) (copy-of-a-book title author irbn)))
IiIlG ( (1

<ivstaff =uaror) (user -borrower)) --> (Ctdoloto-from n <chock-out =uaor =titlo-of Oadd-to n (chocked-out-to -title-of (42 ((chock-out -usor -title-of -author-of =titlo-of) (book (book-available -author-of lar*r) (ia-rtaff

-author-of
Iauthor-of

=borrowor))
=borrowor)))>

=author-of =titlo-of)

l borromor)

Curer
-->

-borrower))

((Sdoloto-iron
(chock-out
Oadd-to

n =nnor -titlr-of

-author-of

-borrowa))

((usor =na~o -status =urr-books) (library -users -lib-books) <book =titlo =author l rubjoct) <<not> (notavail =library =book)) (<not* (ororlimit =urrr =rizo)) (<not> (halcopy -nror =book)) (chock-oat =library -usor -book)) --> <<Sdol*to-from R
(check-out (S&d&to

=titlo-of =author-of =borromor)))) (43 ((<not> (book-atailablo =author-of =titlo-of)) (*not> (chwkad-out-to =tilo-of -author-of =borromor))) --> (((add-to nm (error book-tailablo)))) (44 (<book-railablo Iauthor-of =titlo-of) =borrorer>) (chocked-out-to =titlo-of Iauthor-of
-->

n (lrrt-borromrr

((Sadd-to

um (error

chockad-oat-to))))

-library

-user

=book))

(chockodont Ilibrary =book)))) (2 ((urrr muo -eatus =usr-books) (library =uurorr -lib-bookn) (book =titlo -author wubjoct) (<not> (notarail -library -book)) (<sot> (ororltiit =usor =rizo)) ((not> (hamcopy =usor =book)) (chock-out =library =usor =bookt))
-->

(45 ((tiot> (bouudr -book8 =borromr))) --> (<$add-to m (error boundr)))) (46 <<book Iauthor-of Ititle-of) (<not> (cud-cataloguo -author-of =titlo-of -->
((Sadd-to ) (is-a (1 IIB

=subjoct)))

(error
noaal

card-catolognar)))) rtaff)))

(uror

(parts-of

(2 (book author-of (cud-catalopo

titlo-of)

l ubjoct

author-of

titlo-of)))

5.3

Results

nm (chock-out -library =u8or =book)) um (rorponaiblo =book -usor)))) ((add-to (3 ((limit =anrubor) (ororlirit =wor =riuo)j --> (C)add-to mm (error liait)))) (4 <C-not> (notavail -library =book)j (chockodout =library =bookt))
-->

((Sdoloto-from

(($add-to (5 ((notavail

n (error notavail)))) =library -book) <<not> (chockodout l library =book))) --> <<Sadd-to R (error chockodout))))

1 (is-a (1 (usor rogulu staff))) (puts-of (1 (urorr nuo status books)) (2 (book titlo author rubjoct) (library UI~II booka)))
LEE < (41

((chock-out

=mor

-title-of

-author-of

=borrowor)

The static analyzer is not intended to be a perfect anal.yzer: neither it could be. Its performance is dependent not only on its heuristics as well as on the descriptions being analazed. A demonstration of this is that perspective analysis have, always, had a better performance than viewpoint analysis in the cases studied [9]. Performance here is understood as how well the messages compare with the possible messages produced by an inteligent agent performing the analysis. It also should be kept in mind that the messages produced by the analyzer are advices We should note that the analyzer besides producing relevant messages, also produces a series of redundant messages and messages that could have been dismissed by an intelligent agent. Unfortunately, this last side effect is not easy to overcome. In the next section, we list some of the messages produced by the analyzer that could be claassified under the category of undesirable effects. We performed three viewpoint analysis, each taking a pair of VWPl descriptions. We compare Richs rules with

117

Yues rules, Yues rules with Wings rules, anId Wings rules with Lees rules. For each comparison; we list the probable rule pairs found by the recognition and elaboration parts of the analyzer (Figure 4) and list, in a prettyprinted format, the relevonf messages produced, that is, we present a filtered result of the static analyzer. After each comparison there is a brief analysis of the messages produced. Rich - Yue: The probable rule pairs are (51 21) and (52 21). Follows the relevant messages produced. 1. Richs rules are missing a rule similar to Yues rule 22. 2. Yues rule 21 is missing the agents user <and staff with respect to Richs rule 51. 3. Comparing Richs rule 51 and Yues rule 21 the following objects are in contradiction: none and copyborrower. 4. The attributes of Richs library and Yues librarycopy and Richs check-out and Yues check-out do not correspond. 5. Comparing Richs rule 52 and I-ues rule 2!1, the following objects are in contradiction: not.-library and not-copy-borrower. Ah these messages, being part of the agenda produced by the viewpoint. analysis will bring up discussions between the viewpoint holders about the following prob lems: constraint on the borrowing limit (1) error messages for not hold constraints (S), the role of the agents user and staff (2), the question of responsibility of a user (3), and the questions about attributes (4). These discussions are part of, what we have called, viewpoint reconciliation (Figure 2). Yue - Wing: The probable rule pairs are (21 02), (21 01) and (22 03). The relevant messages are listed below. 1. Yues rules are missing rules similar to Wings rules 5 and 4. 2. Yues rule 21 is missing the objects !not-notavail and not-overlimit and the agent user with respect to Wings rule 1. 3. Comparing Yues rule 21 and Wings rule 2, the following objects are in contradiction: copy-borrower and responsible. 4. Comparing Yues rule 21 and Wings rule 1, the following objects are in contradiction: copy-borrower and checkedout. 5. The attributes of Yues checkout-limit and Wings limit do not correspond. 6. The attributes of Yues book and Wings book and Yues check-out and Wings check-out do not correspond. The messages produced by this comparison raises the

questions about: the constraints (5 and 4), the role of the agent user (2), the notions of responsability and checkedout-to (3 and 4) and the different attributes used (5 and 6). These questions, by being part of the agenda for viewpoint reconciliation, should be resolved by the actors involved in the process of elicitation. Wing - Lee The probable rule pairs are (1 41) (I 42) (2 41): (2 42), (3 43), (3 44), (4 43), (4 44) (5 43), and (5 44). Next we list the relevant merrager produced by the analyzer. 1. Wings rules are missing a rule similar to Lees rule 46. 2. There is 54%* of chance that Wings rule 2 is missing the object is-staff and Lees rule 42 is missing the object not-overlimit. 3. There is 11% of chance that Lees rule 42 is missing the object library and Wings rule 2 is missing lastborrower. 4. Lees rule 42 is missing the object not-hascopy. 5. The attributes of Wings user and Lees user do not correspond. 6. The attributes of Wings check-out and Lees checkout do not correspond. The messages reported in this comparison bring up the following problems: the necessity of adding a cardcatalogue constraint (l), the need to establish the role of library (3), the role of the object is-staff (2), the at,. tributes of book, user and check-out (5 and 6), and the necessity of checking if a borrower has, already, a copy of a book (4). As with the other comparisons, this agenda will drive the processes of evaluation and integration of viewpoints.

Limitations of our Future Work

Method

and

The analyzer, as expected, generated some non relevant messages. For example: in the case of the Yue - Wing comparison, one message mistakenly compares Yues countofcopy with Wings overlimit and Yues greater with Wings limit, when the comparison should be the other way around; In the case of Wing -Lee comparison, the pairs (1 42), (2 41), (3 43). (3 44), (4 45) and (5 44) were considered to be probable rule pairs, when in reality they should not; in the case of Rich - Yue the, attribute diagnosis for the pair (51 21) wss repeated for the (52 21) pair. The heuristics of the analyzer could be improved mainly by using better pattern-matchers and by eliminating redundant messages. By heavily relying on the application vocabulary concept [2], the strategy is very much syntax oThis percentage represents the message degreeof belief, it is at.tributed accordingto the results of the set of scoringheuristic.

oriented. Although being syntax oriented the experiments done so far have demonstrated its usefullness. These experiments used, at a maximum, rule bases of 20 rutes. Its use for larger rule bases was not investigated, but an incremental use of the strategy, for different levels of abstraction [s]~ could help in addressing this problem. Another aspect not dealt with, SO far, is the construction of human-interfaces for the strategy. Further experiments with viewpoint analysis, will not only evaluate its uselfulness in the process of elicitation, and thus on the process of knowledge acquisition. but will possibly suggest improvements that will make its application more productive.

Freeman P. and L&e

J.C.S.P. Requirements Techniquer and Languages. A Survey. Dept. of Computer Science. Unrvcrlty of Calrfomta hme, rubdttod for publication (1988) [3; Hall, R. Computational Approaches to Analogical Reasoning: A Comparative Analysis. Art@cd InteNyence 21, 1 (Jan. 1988), 241-250. Kowalski, R. Software Engineering and Artificial Intelligence in New GenerationComputing. 1984. from an Award kcture on May 15: 1984 in London. 15; S. Ohlsson and P. Langley; PRISM lbtonal and Manual. Tech. Rep. 66-02, University of California, Irvine + Dept. of Computer Science, Feb. 1986. Lee S. and Sluizer S. SXL: An Executable guage. In 4th bfemallonal Workrhop on ware Specificnhon and Derqn (Monterey, 1987). IEEE Computer Society Press, pp. 235 (71 LanSoftCA, 231-

Conclusions

The case study helped to show that it is higlhy desirable to have an early validation in the software construction process. By doing so, it also showed the role of a viewpoint analysis strategy in pointing out problems in the understanding of the situation which we are trying to model. Although the agenda produced by the viewpoint analysis distinguishes between completeness and consistencies that problems between views, it raises a series of problezas may show ambiguities or incompleteness of the source of information in the universe of discourse. By examining different. views of the same universe of discourse we are obtaining a meta insight about what Wing calls the specificand. The evaluation and the integration of views has to deal with those problems, and has to perform the formation of the reconciled view (Figure 2). It should be noted that this process is not a simple technical problem. but it is, in reality, a problem which is related to social aspects of computing, since it deals with several different actors of the universe of discourse. It is interesting to observe that Wing [IS] did a sort of viewpoint resolution in her analysis of the library problem, since she acknowledged the change of information between the several authors involved, but in that case she was the final judge of the analysis. Viewpoint reconciliation should try to be a participative process with all the actors involved in the process. The distinction of completeness problems from consis tency problems is one of the greatest advantages of using a domain based approach [12] [l]. In this approach, a requirements is validated against the domain. Our approach, although not providing the same performance as compared to a domain based validation, has the advantage of not needing the costly construction of a domain.

Leite, J. The Agent Vtewposnt. Tech. Rep. RTP 070, Dept. of Corny. Science, Univ. of Calif., Irvine, Mar. 1987. Leite, J. A Proposal for Appked Research on Requwemen~r Ebolat~on. Tech. Rep. RTP 072, Dept. of Comp. Science, Univ of C&f.. Irvine, Jul. 1987.

[6j

[Q;

Leite, J. litcwpornt Rerolutton

tn Requrremenir Wcttatton. PHD thesis, Dept. of Comp. Science, Univ. of Calif.. Irvine. 198b. G. CORE - A Method for Controlled l.n Proc. 4th ml. conf. on Soficu. Eng. (197Q), IEEE Computer Society Press, pp. 126-135. Intrlkgence. MC Graw-Hill,

[lo:

Mullerg,

Requirement Specification.

ill; il2;

Rich E. Arttficral New York, 1983.

Rich, C., Waters, R., and Reubenstein, H. Toward a Requirements Apprentice. In 4th Internattonal Wortrhop on Software Specsficatmn and Derlgn (Monterey, CA, 1987). IEEE Computer Society Press,pp. 7986. ROES, D. Structured Analysis (SA): A Language on Defor Co mnmnicating Ideas. In fitonal rrgn Techncquer, Freeman and Wasserman, Eds., IEEE Computer Society Press, Long Beach, CA 1980, pp. 107-125. Steele G., and Sussman, G. The Revised Report on Scheme, a Dsalect of LISP. Tech. Rep. Al Memo No. 452, MIT, Jan. 1976. Wing J. A Larch Specification of the Library Problem. In 4th Inlemational Wortrhop on So& cuare Specificataon and Derign (Monterey, CA, 1987), IEEE Computer Society Press, pp. 3441. Wing J. A Study of 12 Specifications of the Library Problem, in IEEE Software $4 (Jul. 1988), 6676. Yuc K. What Does It Mean to Say that a Specification Is Complete? In 4th hlematronal Workrhop on Software Specificalwn and Derrgn (Monterey, CA, 1987), IEEE Computer Society Press, pp. 34-41.

[13j

il4;

[l$

iW

References
Fichs, S. Automating
the Analysis Process. An Example. In 4th Intemakonal CTorLshop on Software Speetfieatlon and Dcrlgn (Montenr, CA, 1987),IEEE Computer Society Press, pp.
58-G