A metalanguage design for sessions with group decision support systems

Computer Science in Economics and Management 2:151-169, 1989. 151 © 1989 Kluwer Academic Publishers. Printed in the Netherlands.

A Metalanguage Design for Sessions with Group Decision Support Systems NIV A H I T U V and I S R A E L S P I E G L E R Computers and lnformation Systems Program, Faculty of Management, Tel Aviv University, Tel Aviv, 69978, Israel

(Received: 19 January 1989)

Abstract. This paper proposes a metalanguage for representing communication among participants in a session of a group decision support system (GDSS). Such a vehicle can be used for setting standards and designing specific user interfaces with GDSS.

Three different roles of participants are identified: chairperson, chauffeur and regular participant. The tasks and activities of each role are analyzed. Based on the analysis, communications requirements are derived. The requirements lead to a design of a metalanguage consisting of 15 different commands. The paper concludes by displaying the structure and syntax of each command.

The work described here is conceptual and could be considered as a proposal for GDSS language design.

Key words. Group decision support system, group decision support language, formal languages.

I. Introduction

In large organizations, organizational decision making inevitably involves groups of people (executives). This has given rise to requirements for new decision support systems, which are to accomodate multi-user environments. With the advancement in computer technology, particularly in the area of distributed electronic workstations, the concept of DSS has been applied to support organizational decision making. As a result, the idea of a Group Decision Support System (GDSS) has been proposed by several management information systems (MIS) researchers, (e.g., [5, 6, 12]). Empiri- cal findings suggest that the technology of GDSS significantly affects idea generation in group decision making processes [13].

A group decision support system can be defined as a computer-based system that is used to support collective decision-making processes. A collective decision making process can be viewed as a situation in which

(i) there are two or more persons, each characterized by his/her own perceptions, attitudes, motivations, and personalities;

(ii) participants recognize the existence of common problems and goals; and (iii) participants attempt to reach a collective decision.

Decisions may take many forms: rendering an opinion, giving a solution for a problem, making a specific recommendation, defining alternative courses of action, handing down a verdict, or stating a general policy. Two aspects are present in any

152 NIV AHITUV AND ISRAEL SPIEGLER

decision-making activity: one is the content, which has to be valid and meaningful, and the other is how the decision is made, i.e., the process [1, Ch. 3, 16].

A decision made which disregards to these two aspects frequently leads to unenthusiastic participation of those who must carry it out. For instance, calling for a vote when the issue has not been well-discussed gives a bare majority decision, resulting in hostile feelings among those who have been defeated. Perfunctory attention to the how side of decision-making frequently entails a need to reconsider the decision itself [9, 10].

The above argument has called for better understanding of the way a group makes a decision. Two factors are involved in this process: participation and communication. Here, participation is more than just being there or giving someone else's decision a vote of confidence, but it also involves sharing of one's own expertise with others in solving a common problem. Communication, also, is more than passing information around, but includes presenting one's idea clearly and meaningfully to all. Communication is one of the themes of this paper, and will be further discussed in subsequent sections.

As has already been mentioned above, communication is a very important factor in the group decision-making process [13]. Moreover, it has emerged as the core issue in designing and implementing an effective GDSS. Because there is a variety of users (e.g., a chauffeur, a chairperson and other participants), categories of the users and their communication needs have to be determined so that commands to meet the needs can be defined for each category. This paper concentrates upon the logical definition of commands and command options. The goal is to derive logical requirements and a general format for the commands and their options which can be used as the basis for future software design. To meet this goal, the following tasks have to be accomplished:

1. To identify GDSS users and define their communication needs. 2. To derive definitions for the commands and command options. 3. To determine the command repertoire for each category of GDSS users.

For these tasks to be accomplished, it is necessary first to determine the nature of group decision-making process. The participants could then be identified, and communication requirements among these participants would be found. Finally, the logical definition of the commands and their options for each category of participants would be derived.

Before starting with these tasks, we would like to emphasize that the metalanguage proposed here constitutes a conceptual framework for GDSS sessions. It is not limited to a particular programming language nor does it require that lay users learn a new language. It can be incorporated into GDSS by introducing simple commands, by selecting a command from a menu, by 'taking a ride' on existing E-Mail or OS commands, or by assigning operations to the keyboard function keys. In short, it is an 'open-end' framework for GDSS designers when they consider the implementation

of a GDSS in a realistic setting.

METALANGUAGE FOR DECISION SUPPORT SYSTEMS 153

The next section delineates common scenarios of group decision-making processes. Section 3 derives the communication requirements for the various participants of a GDSS session. Section 4 formulates the metalanguage structure. Section 5 lists and explains the commands. The last section provides a summary and some concluding

remarks.

2. Structured Communication

In a group decision-making process every participant of a group meeting should have the ability to express his/her point of view in a well-defined manner. There is,

therefore, a need to define some structure to the communication process. The idea of utilizing computerized communication is very desirable, as it has the

ability to provide structure and to enhance the human communication process. Aspects of structure specification such as the number of participants; the roles they play; who may communicate with whom, how, when, and under what conditions; are all inherent in any communication set-up and certainly when done via computer systems. Even where a communication structure is not explicitly designed and imposed on a group, there will be an implicit or emergent structure that dictates the communication; e.g., Mail Utility or Local Area Network (LAN) [18].

There is an infinite number of different human communication patterns that can be mediated and facilitated by a computer. A couple of common methods of structuring the human group decision-making process in other communication modes are discussed below, followed by recommendations on how these might be implemented in a computer-assisted environment.

2.1. DELPHI STRUCTURE

Many designs for structured communication processes that have proven successful in addressing their particular problems are reported in the literature on Delphi [3]. They may be summarized as consisting of the following three phases:

Phase 1:

The objective of the meeting is specified. Participants are then asked to give their initial responses; for example, present their arguments and estimates, and the assumptions they have made in order to arrive at the estimates. The responses are anonymously collected, and duplications as well as excessive language are eliminated. Next, the summarized results are presented to the group as possible working assumptions.

Phase 2:

Participants are asked to vote on the importance and validity of the summarized results presented. Additional arguments, supportive or otherwise, are also requested.


Then, the votes are collected and ranked accordingly before being fed back to the participants.

Phase 3."

The above two phases are repeated until they converge to a consensus.

2.2. NOMINAL GROUP TECHNIQUE

The Nominal Group Technique is a group meeting in which a structured format is utilized for decision making among individuals seated around a table [4]. Its procedure is described as follows:

Phase 1:

The goal of the meeting is specified. Participants then silently and independently generate their ideas on the problem or task in writing.

Phase 2:

After a reasonable time has elapsed, each participant - one at a time, in turn, around the table - is asked to present one of his/her ideas to the group without discussion. The ideas are recorded as they are presented, then summarized and fed back to the group.

Phase 3."

When every participant has presented his/her idea, the recorded results are discussed

for the purpose of clarification and evaluation.

Phase 4:

After the discussions have been concluded, the meeting ends with an anonymous voting on priorities by each participant through a rank ordering or rating procedure.

The group decision is the pooled outcome of individual votes.

2.3. RECOMMENDED STRUCTURE FOR A GROUP DECISION SESSION

The above methods are common examples of group decision-making processes. One might construct other methods, or incorporate ingredients of the above methods into a new one (e.g., add an iterative Delphi-type phase to the rank ordering phase of the nominal technique). The methods were brought to demonstrate the spirit of a possible scenario. In this section we try to extract the main principles of a group decision-

making session.


The objective of the group decision-making process is to create collective intelligence capabilities that demonstrate an ability to produce results and to make better decisions than any member of the group acting individually. The underlying idea is that an explicitly designed communication structure will be more likely to produce a fruitful group decision in terms of both the efficiency of the process and the quality of the results.

The group structures presented above share the following characteristics:

1. Anonymity option. 2. Independent generation of ideas or judgments, by assuring that all participants

have the opportunity to think and record their ideas or judgments before receiving those of others.

3. Mechanisms for assuring equality of opportunity to participate. 4. There is at least one facilitator (e.g., chairperson) to assure the flow of communi-

cations in a prestructured manner, rather than relying on informal leadership from within the group itself.

5. Specification of allowable subjects and forms of communications. 6. Organized feedback to the group of the input from the participants and the

aggregate decision trend that is emerging. 7. Communication level allowed between participants is specified. 8. The mode of communication is specified (e.g., computerized, written, etc.).

Based on these characteristics, we outline a general scenario for a GDSS session. The communication language requirements will derive from the scenario presented below:

Phase 1: Introduction

At the beginning of the session, all the participants are introduced to one another by the chairperson (see details of this and other roles below). However, if the participants have previously been acquainted with one another, this step may be omitted. Next, the chairperson states the agenda and objectives of the meeting. A computerized GDSS is used in this phase to display participants' names, titles, and the agenda on the public screen.

Phase 2: Individual Preparation

If more than one objective has to be met, one is then selected for consideration. Participants are then allowed to silently and independently generate their ideas on the problem or task in writing. For this purpose, they may utilize available decision support software existing in the system or they may load into the system data and software they have prepared earlier. The time allocated may vary, depending on how well the participants are prepared in advance.


Phase 3: Individual Statements

After a reasonable time has elapsed, the chairperson then asks each participant, in turn, to present one of his/her ideas to the group without discussion. The ideas are recorded as they are presented, then summarized and fed back to the group. When

a computerized GDSS is installed, this phase can rely on displaying ideas on the public screen.

Phase 4: Group Discussion

When all participants have presented their individual ideas, the recorded results are discussed for the purposes of clarification and evaluation. Any participant who wishes to elaborate on his/her ideas may request the floor. The chairperson controls who has the floor, and for how long. In a computerized GDSS session, this phase interweaves oral discussion and the use of the public screen.

Phase 5: Additional Iterations and Conclusions

When all discussions have been exhausted, the chairperson motions for a vote. Participants are asked to cast their votes anonymously. If there are more items on the agenda to be considered or the votes are not satisfactory, Phase 2 to 5 are repeated. Note that voting itself can be an iterative activity in which a number of rounds may take place, or even a Delphi method may be exercised. The group decision, then, is the pooled outcome of the individual votes. A computerized GDSS is used in this phase to collect and analyze the votes and provide feedback to the participants.

3. Communication Requirements

In the last section, a group decision-making process structure was proposed. The next step is to identify the types of participants involved in the process and determine the communication requirements among them. This will be done by considering the roles and activities of each participant in the decision-making process.

There are three main types of participants in a group decision-making process [10]. These are:

• Chairperson • Chauffeur (go-between) • Regular Participants

Each of the types plays different roles in the process, as will be portrayed later. Figure 1 illustrates the communication channels required for a GDSS session. These channels may be in the form of verbal communication, if the participants are

all within a room; or some type of utility which will allow the parties to communicate with one another, either through a normal telephone link or through a computer

METALANGUAGE FOR DECISION SUPPORT SYSTEMS

,.. °*J ..-'J

~'rorn Chairperson

157

:I -- ~rom Chauffeur To Ch~feur

Fig. 1. Communication channels in a group decision-making process.

system and/or network. Each of the participants is equipped with a personal computer which is linked to a corporate mainframe. The entire system provides for all forms of communications between the participants, e.g, electronic mail, message transfer, uploading and downloading of files, and the like. A public screen is used to display common information.

By considering the phases of the group decision-making process, it is possible to identify the following roles and activities of the participants:

3.1. CHAIRPERSON

The role of the Chairperson is to control the meeting. It is his/her responsibility to ensure that the meeting is conducted in an atmosphere which is conductive to a converging decision. The activities to be performed by the Chairperson are identified below:

• Introduce participants. • State meeting agenda and if necessary, make appropriate changes to the agenda. • State session objectives and arrange and select agenda items. • Evoke response and give each participant an opportunity to express his/her idea(s)

during the meeting. • Collect responses from participants either directly or anonymously. Anonymous

messages sent to the Chairperson may later selectively be discussed with all participants.

• Control the floor. This includes arranging the order in which the participants are to give the presentation and granting participants another round of presentation if requested.


• Compile response collected from the participants. • Feedback, response and inform the participants of what has been expressed and

recorded. • Conduct voting to determine the outcome of the session. • Collect votes of participants and report the results. • Control time allocated to participants and see that the group reaches a decision

within a given time. • Communicate with others. The Chairperson must encourage and promote the

exchange of ideas and thoughts. • Wrap-up and summarize the session.

3.2. CHAUFFEUR (GO-BETWEEN)

The Chauffeur (or 'go-between' person) has an important and active role in the GDSS process. He/she has to determine, prior to the session, the type of meeting to be held and the expectations the group has as to what it hopes to accomplish during the meeting. In addition, the Chauffeur provides technical assistance to the group decision-making process. It is an important role, where the Chauffeur often deter- mines the type of software a group employs, especially when high technology equipment is being used. The Chauffeur prepares the meeting equipment before the meeting commences, and provides technical assistance throughout the process. He/She may also be required to execute some system commands for the Chairperson and/or for regular participants. Due to the high system privilege granted to the Chauffeur, it is not recommended that a group member be selected to perform this role. In other words, the Chauffeur is a highly skilled technical individual and a key factor in determining whether a meeting is run successfully without being a member of the decision making group.

The activities the Chauffeur performs in a group-decision-making process are as follows:

• Set-up meeting workstations. It is the duty of the Chauffeur to prepare and test the workstations to be used in the meeting, ensuring that all function properly. He/she may also be required to open time-sharing sessions for the participants, or to grant system privilege for the participants as necessary.

• Control public screen. Upon directions from the Chairperson, the Chauffeur will open or close the access channel to the public screen of a regular participant.

• Control print queue. The Chauffeur is to ensure that a print queue is set-up and operates smoothly.

• Control data storage. The Chauffeur is in charge of all the operations on the system's storage volume.

• Run record-keeping software. • Execute Chairperson's commands. The Chauffeur may be required to assist the

Chairperson and may have to execute some of the more advanced commands for him/her.


3.3. REGULAR PARTICIPANTS

It is the purpose of the group decision-making process to elicit ideas and expertise from group members. To achieve this, the participants' role is to share and contribute their expertise and resources in arriving at a satisfying group decision. The Chair- person may also be regarded as one of the regular participants in another role.

The activities to be performed by each regular participant are described below:

• Read agenda. It is recommended that the agenda be displayed on the public screen at the beginning of the meeting; however, if a participant wishes to see it again during the meeting, he/she may access it any time through the agenda handling system.

• Read stated objectives. It is recommended that the objective(s) is(are) also displayed on the public screen. However, during the meeting a participant may wish, for example, to reconfirm the objectives, he/she may access it again through the appropriate system.

• Get relevant information. The participants of a group decision-making process are required to generate some ideas and/or alternatives privately and to share them with the group later on. They may, therefore, need to retrieve some additional information which is already stored in the system or is to be loaded to it.

• Run application software. A participant may need to access, for example, some individual decision support system.

• Respond to Chairperson. • Communicate with others. • Present ideas. Each participant is to contribute his/her ideas to the group, by

presenting his/her solution and/or alternatives. • Express ideas anonymously. Some participants may not feel comfortable to

express their ideas openly, but still wish to make their opinion known to the group. They may do so by sending anonymous messages to the Chairperson (a computerized GDSS should include an option to erase user identification upon trans- feting a message).

• Read meeting records. Participants are allowed to access the record-keeping system, to only read what has been recorded during the meeting.

• Help inquiry. The participant may request help from two main sources: the system help functions and the Chauffeur. It is recommended that there be sufficient help information available to every participant, both on-line and on printed documents.

• Request the floor to present new ideas and points of view. • Transfer files. Since needed information may reside in different computer systems

on the network, participants may need to transfer necessary files and data between these systems.

• Cast vote. Votes are collected from the participants. This process may iterate. • Print document. Participants may wish to have hardcopies of the recorded docu-

ments and graphs for reference. • Logout. Participant should logout from systems to avoid unauthorized attempts

to access their data.


From the above discussion on the roles and activities of all members of the group decision-making process, it is possible to design some means to model the meeting process. This is necessary for the purpose of determining the communication requirements and command repertoire for each party.

Before we describe the GDSS metalanguage, we would like to stress that a computerized GDSS in general, and a metalanguage in particular, are only a means to facilitate group decision-making processes. Therefore, a GDSS should be friendly and easy to use. It should not impose very rigid and confusing syntax and formal rules on the participants, but rather generate a pleasant atmosphere that encourages creativity. This may be done, for example, through a menu-driven friendly user interface. The following sections are formal in nature because that is the only way to present the concepts of a metalanguage. Nevertheless, the implementation of these concepts should be performed 'with the face to the lay user'. Otherwise, it is likely that participants will renege to traditional uncomputerized sessions.

4. Metalanguage Structure

Before we attempt to define and enumerate the GDSS communication format and its command repertoire, a global metastructure is drafted. The metastructure gives an overall framework to commands and makes the design of particular user languages or interface more uniform and cohesive. It also aids potential users in learning and understanding the communication format and protocols.

The model represented here is an adoptation of the BNF (Backus-Naur form) metalanguage [2]. This form of syntax representation is suitable for description and language design. A similar form is used to represent man machine interface in a database environment [7] and in analysis of natural language queries [17]. Such forms are found in AI applications of natural language processing; see for example the TEAM system [11], or YANLI [8].

A complete survey of metalanguage techniques is beyond the scope of this paper. The interested reader is referred to several such surveys found in [14] or in [15].

The overall structure of the Group Decision Support Language (GDSL) is

GDSL =: command [what] [where] [option]

The structure indicates that every sentence in the language must start with a command VERB and optionally followed by either a 'what' clause which is the source entity of the command; a 'where' clause which defines the target destination of the command; and 'options' which give certain conditions and qualifications pertaining to the command. These elements are elaborated below:

command =." CLOSE [ DELETE[ DISPLAY I EDIT I GET I HELP[ LOGIN I LOGOUT [ OPEN[ PRINT[ READ [ RUN I SAVE] SEND[ SWITCH I


The full sematic of each of these commands is given in the section that follows this

overall description of GDSL.

what =." file [ system [ profile I queue[ channel[ device

Each of these elements identifies a source of the particular command. For example

READ {file}

represents the simple request to read a named file; e.g., READ agenda where

agenda is the name of the current file in which the agenda is stored.

The what element of the language contains the various files, systems, profiles, the queue of people who want the floor, or any other service such as channels and devices connected to the communication network. It should be noted that this metastructure defines the overal picture of GDSL. Specific combinations of commands and parameters need further description as not all may have a meaning in the context of

GDSS. The various elements of the 'what' clause are defined below:

file =.. [d:]name[.ext]

system =." name [, n ame] . . .

profile =." name [, name] . . .

channel =, n (n is a designated number)

device =: PRINTER I PLOTTER I SCREEN[ MODEM I - - •

The where clause defines the target of the command. This definition includes:

where =." person I station I file1 database [ device[ ALL

and the elements in the definition are:

person =: name [, name] . . . I nickname [, nickname] . . .

station =, m (m is a designated number)

Not every command needs to have a where clause. This is indicated by the brackets [] in the definition. Also, the where clause may be optionally preceded by a what clause. For example, the structure

PRINT {what} {where}

defines the specific command: PRINT sales-data PRINTER1 The options clause contains several options and conditions that relate to the command. They are defined as follows:

options =, condition[ security I device

162 NIV A H I T U V A N D I S R A E L S P I E G L E R

G D S L =: c o m m a n d [what] ]where] ]option]

C o m m a n d =.- Close I D E L e te [ DISplay I Edi t I Get I Help [ Log in [ L O G O U T ] O p e n [ Pr in t ] R ead I R U N [ Save [ SEnd SWitch [

wha t =, file [ sys tem I profile [ queue I channe l I device

file =: [d:]name[.ext]

sys tem =, n a m e [, n a m e ] . . .

profile =.- n a m e [, name] . . .

channe l =.. n (n is a des ignated number )

device =.- P R I N T E R I P L O T T E R I M O D E M ] S C R E E N I • • •

where =, pe r son [ s ta t ion [ file [ da t abase I sys tem ] device [ A L L

person =, n a m e [, name] . . . ] n i ckname [, n ickname] . . .

s ta t ion =: m (m is a des ignated number )

op t ion =, condi t ion I securi ty I device

condi t ion =, n a m e op value

security =: read I write I mod i fy [ delete [ a n o n y m o u s

o p = : = l > [ > = l < [ < = [ < >

Fig. 2. MetaS t ruc tu re of G D S L .

where

condition =: name op value

security =." read [ write I modify I delete [ anonymous

conditions may restrict a command only to certain values. For example,

PRINT sales-data PRINTER1 department = 123

o r

SEND report l m < 5 (to stations 1, 2, 3, 4)

The entire meta-structure of GDSL is shown in Figure 2.

5. Command Repertoire

This section outlines and illustrates the actual structure and semantics of each command in the proposed GDSL. The section has two parts: a summary of the commands grouped by GDSS roles and a detailed description of each command.


5.1. COMMAND ASSIGNMENT

The entire set of commands of the proposed metalanguage should not be at the disposal of every participant of a GDSS session. There are commands authorized for the Chairperson only, for the Chauffeur, and for the regular participants. There are, of course, commands which all parties may use depending on the type of usage desired. Figure 3 provides a summary of the commands with an indication as to who

may use each. While the data in Figure 3 speaks for itself, we note several points of interest. First,

authority of certain commands is given only to the Chauffeur. For example, the OPEN and CLOSE commands which deal with allocating devices and facilities of the system fall in the responsibility area of the Chauffeur. Second, there are problems of access and security. Therefore, the READ and DISPLAY commands are restricted to the Chairperson only where the what clause is any particular participant's profile. Third, effort is made to have the entire repertoire of commands available to all participants and that commands be identical in structure and form across various users of GDSL. Finally, while no technical background is assumed for GDSS participants and chairperson, the Chauffeur must be acquainted with system and communication facilities. He or she deals with allocation, transfer and control of the technical aspects of the session and acts as a resource person for the rest.

5.2. THE COMMANDS

We list the commands alphabetically. Each command may be abbreviated as indicated by the capital letter(s) defined below.

CLOSE

Format: Close {what} {where} {option}. The CLOSE command is used by the

Chauffeur to disable certain facilities or access from session parties. The what clause may include: file, system, profile, queue, channel or device. The where clause is optional but may be one of the following:

person, station, file, database, device or ALL. Example:

Close 5 Smith

DELETE

Format: DELete {what} {where} {option} The DELETE command lets user erase data from system facilities provided they have the authorization. The what clause here has meaning for: file, profile, and queue. The last

two are restricted. The where clause in this command is interpreted as FROM and is

relevant to these parameters: file, database


COMMAND

CLOSE

DELETE

DISPLAY

file profile queue

ED IT

file profile queue

GET

HELP

LOGIN

LOGOUT

OPEN

PRINT

READ

file profile

i RUN

i SAVE

SEND

SWITCH

Chairperson

/ /

Chauffeur Participant

/

/

Fig. 3. Command summary.

Example: DELete quartl year-data

DISPLAY

Format: DISplay {what} {where} The purpose of the DISPLAY command is to bring certain information

to the various workstations and devices of the session participants. This is merely a means to show others any desired information.

The what clause: file, profile, queue The where clause: person, station, device, ALL Example :

DISplay agenda ALL Note, there is a difference between the DISPLAY command and the


READ or GET commands where the first one is a sending and the

latter two are receiving commands.

EDIT

Format: Edit {what} The EDIT command allows session participants to create or change the

content of files. Normal access restrictions hold for this command as well.

The what clause: file, profile, queue

Typically, there will be no where clause as this is associated with the SAVE or SEND commands explained below.

Example: Edit myfile

GET

Format: Get {what} {where}

The semantics of this command are to obtain certain data or message FROM a sending member of the group.

Here, the what clause relates to: file, profile, and queue, and the where clause: person, station, file, database.

Example: Get sales-data Smith

HELP

Format: Help {what} The HELP is the central automated aid to session participants in all

their needs. This is an on-line assist facility that should be context sensitive; that is, provide the help base on the particular situation of the user. Normally, the HELP command is preprogrammed into one of the Function Keys of the keyboard or is part of a screen m e n u .

LOGIN

Format: LOGIN {system} . . . This command allows users to hook-up to any system available on the

network. Such login may be recursive, as indicated by the ellipses ( . . . ) . That is, while in one system, a user may login into another.

LOGOUT

Format: LOGOUT {system} . . . Issuing this command, any participant can disconnect from the system

he or she uses. The ellipses ( . . . ) shown on the command format has a special semantics to indicate that a user may logout from more than


one system. This happens where the user has 'nested' into several systems while in session.

OPEN

Format: Open {what} {where} {option} This a Chauffeur command to enable session parties the use of system

facilities - usually devices or channels. The what clause refers to queue, channel or device. The where clause relates to person or station. Example:

Open 5 Smith

PRINT

Format: Print {what} {where} {option} This command lets users get a hardcopy of a file or document for

permanent use. Normally, the document sent to the printer is already saved, but users may also want to have a PRINT SCREEN facility where the data displayed on their screen or the public screen are printed.

The what clause: file, profile, queue The where clause: device, where the device is a printer, plotter or any

other media. Example:

Print myfile LASER JET

READ

Format: Read {what} {where} {option} The READ command obtains data from external sources. This includes

getting a file from another database or accessing a profile (subject to authorization) of another participant. The difference between the GET and READ commands are that the former is interactive in nature allowing users to get data from people who are currently logged in, while the latter allows access to permanent system data facilities also.

The what clause here represents: file, profile, and queue. The where clause, having the meaning of FROM, covers: person,

station, file, and database elements. Example:

Read quarter2 dbase3

RUN

Format: RUN {what} {where}


This command allows users to execute files on desired systems. The what clause includes: file, or queue. The where clause directs the source file to a desired system. If omitted,

the current system is the default. Example:

RUN sales-analysis

SAVE

Format: Save {what} {where} {option} Using this command participants store permanently copies of their data

in the computer memory. The what clause: file, profile, queue. The where clause: database or system. While saving, a user may indicate the security status of the file. Example:

Save sales-data dbase5

SEND

Format: SEnd {what} {where} {option} This command is used to send messages and files across participants and

stations on the network. The what clause refers to: file or profile.

The where clause, having the meaning of TO, sends the desired data to a person, a station or ALL.

Example:

Send agenda ALL

SWITCH

Format: Switch {what} {where} This command lets users move from one system to another. This is

particularly useful during GDSS sessions where a Chairperson, or another participant, make a statement and people want to check it on their relevant software system.

Both the what and where clauses refer to systems. • Example:

Switch Lotus FW2

6. Summary and Conclusion

This paper has presented a logical design of communication commands for a session using a Group Decision Support System. The design approach is based upon t h e activities involved in a group decision-making process. The first step was to typify a

168 NIV AH1TUV AND ISRAEL SPIEGLER

structure for the session to be used and to incorporate Delphi and Nominal Group Technique into it. The characteristics of both techniques were combined to form a structure for a recommended group decision-making process.

The next step was to identify the roles and activities of all parties to be involved in the recommended group process. The parties and their roles may be briefly summarized as follows:

• Chairperson: controls the meeting and ensures that the meeting is conducted in a manner which is conductive to a converging decision.

• Chauffeur (go-between): prepares the meeting and provides technical assistance throughout the process.

• Regular Participants: share and contribute their expertise and resources.

However, they all have one common role: to ensure that all relevant ideas and alternatives have been expressed and thoroughly discussed so as to enable a satisfying group decision to be reached.

Based upon the activities identified for each of the above roles, three sets of requirement groupings, or repertoires, were derived. These groups also summarize how the activities of a group decision-making process could be viewed from the Chairperson's, the Chauffeur's, and the regular Participants' perspective. Based on these requirements, a common metalanguage form a GDSS session was proposed.

It must be realized that the product of this paper is the logical design of communication commands. For them to be successfully implemented will greatly depend upon the availability and limitations of the current information technology, including computer hardware/software systems, communication techniques, and personnel. Therefore, it is recommended that the next phase towards implementation be a detailed technical feasibility study of the equipment and personnel, based on the requirements proposed by the findings of this work. These should include user interface and human engineering aspects. It should be noted, once again, that the implementation of the ideas presented here requires much attention to user friendliness and ease of use. In no way participants should feel imposed upon by a formal combersome syntax. Therefore, much attention should be paid to possible use of function keys, self-explanatory commands, and menu-driven options. Further research in this area is required in order to determine the adequacy of various programming languages, and their applicability to GDSS sessions.

References

1. Ahituv, N. and Neumann, S. (1986), Principles of Information Systems for Management, W. C. Brown, Dubuque, Iowa, 2nd ed.

2. Backus, J. W. (1960), The syntax and semantics of the proposed international algebraic language of the Ziirich ACMGAMM conference, Proceedings of the International Conference on Information Processing, UNESCO, pp. 125-132.

3. Dalkey, N. C. (1972), Studies in the Quality of Life: Delphi and Decision Making, Lexington Books, Lexington, Mass.


4. Delberg, A. L., Van de Ven, A. H. and Gustafson, D. H. (1975), Group Techniques for Program Planning, Scott-Foresman & Company, Glenview, I11.

5. DeSanctis, G. and Gallupe, R. B. (1985), Group decision support systems: a new frontier, Data Base, Winter 1985, 3-10.

6. DeSanctis, G. and Gallupe, R. B. (1987), A foundation for the study of group decision support systems, Management Seience, 33 (5) (May 1987), 589-609.

7. Ein-Dor, P. and Spiegler, I. (1985), The answerability of database queries, Information Systems, 10(3), 261-270.

8. Glasgow, J. C. (1987), YANLI: A powerful natural language front-end tool, AIMagazine, 8(1), 40-48. 9. Gray, P. (1981), The SMU decision room project, Transactions of the First International Conference on

Decision Support Systems, Atlanta, Georgia, June, 1981. 10. Gray, P. (1983), Initial observations from the decision room project, Transactions of the Third Inter-

national Conferenee on Decision Support Systems, Boston, Mass., June 1983. 11. Grosz, B. J., et al. (1987), TEAM: An experiment in the design of transportable natural language

interfaces, Artificial Intelligence, 32, 173-243. 12. Huber, G. P. (1984), Issues in the design of group decision support systems, MIS Quarterly,

September, 195-204. 13. Nunamaker, J. F., Applegate, L. M. and Konsynski, B. R. (1987), Facilitating group creativity:

experience with a group decision support system, Journal of MIS, 3(4) (Spring 1987), 5-19. 14. Pereira, F. C. and Warren, D. H. (1980), Definite clause grammars for language analysis - a survey

of formalisms and a comparison with augmented transitional networks, Artificial Intelligence, 13 (1980).

15. Sager, N. (1981), Natural Language Information Processing, Addison Wesley (Chapter 2), Reading, Mass.

16. Simon, H. A. (1958), Models of Man, Wiley, New York. 17. Spiegler, I. and Elata, S. (1988), A priori analysis of natural language queries, Information Processing

& Management, 24(6), 619-631. 18. Stallings, W. (1984), Local Networks - An Introduction, Macmillan Publ. Co., New York.

Documents

A metalanguage design for sessions with group decision support systems