Citation
Decision support service for distributed conferencing system

Material Information

Title:
Decision support service for distributed conferencing system
Creator:
Kakarparti, Aparna
Place of Publication:
[Gainesville, Fla.]
Publisher:
University of Florida
Publication Date:
Language:
English

Subjects

Subjects / Keywords:
Conference tables ( jstor )
Databases ( jstor )
Deadlines ( jstor )
Decision support systems ( jstor )
Electronics ( jstor )
Information retrieval ( jstor )
Political candidates ( jstor )
Rounds ( jstor )
Short circuits ( jstor )
Tin ( jstor )
Computer and Information Science and Engineering thesis, M.S ( lcsh )
Computer conferencing ( lcsh )
Design support systems ( lcsh )
Dissertations, Academic -- Computer and Information Science and Engineering -- UF ( lcsh )
Teams in the workplace -- Data processing ( lcsh )
Genre:
government publication (state, provincial, terriorial, dependent) ( marcgt )
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

Notes

Summary:
ABSTRACT: Decision support system (DSS) is a computer-based system that facilitates the solutions of problems by a group of people who have a joint responsibility to reach decisions. Voting mechanism is one of the tools of DSS. The Distributed Conferencing System at the University of Florida is a distributed package providing real-time support for cooperative work. This work presents the decision support system for Distributed Conferencing System (DCS) v.2. The DSS developed is a flexible and friendly system that allows people to initiate, terminate and participate in a decision process within the context of a conference. It provides on-line voting and has an automated vote collection mechanism. It allows members currently not logged on to the conference to be the voters in a decision process. It provides flexibility to the user to set time constraints on a decision process. It also supports flexible automated reporting. The system provides the users with different voting methods like Majority, Plurality, Ranking, etc. The system allows the users to save their requirements as templates, which can be reused in future. These templates can be used by other members of the conference depending on their access rights.
Summary:
"ABSTRACT (cont.)" The system also handles several issues that come up during a decision process like change of vote and member dropouts and provides several features like Short Circuit evaluation, Archival storage and withdrawal that add more flexibility to the system. Moreover, the system provides a friendly user interface and an API that allows conference services a means to perform the decision-making processes for conference control activities. The interface allows both the users as well as other services of the system to initiate, participate, and query a decision process.
Thesis:
Thesis (M.S.)--University of Florida, 2002.
Bibliography:
Includes bibliographical references.
System Details:
System requirements: World Wide Web browser and PDF reader.
System Details:
Mode of access: World Wide Web.
General Note:
Title from title page of source document.
General Note:
Includes vita.
Statement of Responsibility:
by Aparna Kakarparti.

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright Kakarparti, Aparna. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
12/1/2012
Resource Identifier:
029834330 ( ALEPH )
1109846321 ( OCLC )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

DECISION SUPPOR T SER VICES F OR DISTRIBUTED CONFERENCING SYSTEM By AP ARNA KAKARP AR TI A THESIS PRESENTED TO THE GRADUA TE SCHOOL OF THE UNIVERSITY OF FLORID A IN P AR TIAL FULFILLMENT OF THE REQUIREMENTS F OR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORID A 2002

PAGE 2

Cop yrigh t 2002 b y Aparna Kak arparti

PAGE 3

T o My w onderful paren ts

PAGE 4

A CKNO WLEDGMENTS I wish to express m y sincere gratitude to m y advisor, Dr. Ric hard Newman, for all his supp ort and guidance throughout m y graduate studies. Without his guidance and encouragemen t this w ork w ould not ha v e b een p ossible. I also thank Dr. Randy Cho w, Dr. Stev e Thebaut and Dr. Jonathan Liu for serving on m y committee and for their v aluable commen ts. I w ould also lik e to thank mem b ers of the DCS team Vija y Manian and Ra vi for their critique and v aluable commen ts. Last but not least I w ould lik e to thank m y family and friends for their lo v e and supp ort. iv

PAGE 5

T ABLE OF CONTENTS page A CKNO WLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ivLIST OF T ABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ixLIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xABSTRA CT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiCHAPTERS 1 INTR ODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11.1 Distributed Conferencing System . . . . . . . . . . . . . . . . . .11.1.1 Conference Con trol Subsystem . . . . . . . . . . . . . . . .11.1.2 Database Subsystem . . . . . . . . . . . . . . . . . . . . . .11.1.3 Comm unication Subsystem . . . . . . . . . . . . . . . . . .11.1.4 Access Con trol Subsystem . . . . . . . . . . . . . . . . . .21.1.5 Notifcation Subsystem . . . . . . . . . . . . . . . . . . . .21.1.6 Decision Supp ort Subsystem . . . . . . . . . . . . . . . . .21.1.7 Secure Comm unication Subsystem . . . . . . . . . . . . . .21.2 Group w are and Computer-Supp orted Co op erativ e W ork . . . . . .21.3 Decision Supp ort Systems in Group w are Applications . . . . . . .41.4 Decision Supp ort Service in Distributed Conferencing System . . .51.5 Organization of Thesis . . . . . . . . . . . . . . . . . . . . . . . .62 RELA TED W ORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72.1 CSCW and Group w are . . . . . . . . . . . . . . . . . . . . . . . .72.2 Group Decision Supp ort System . . . . . . . . . . . . . . . . . . .82.3 Existing Group w are Applications . . . . . . . . . . . . . . . . . .102.3.1 Conferencing Systems . . . . . . . . . . . . . . . . . . . . .102.3.2 IBIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122.3.3 Electronic Meeting Systems . . . . . . . . . . . . . . . . . .142.4 Motiv ation for Decision Supp ort Services . . . . . . . . . . . . . .162.5 Issues in a Decision pro cess . . . . . . . . . . . . . . . . . . . . . .172.5.1 V oting Metho ds . . . . . . . . . . . . . . . . . . . . . . . .172.5.2 Tie Resolution . . . . . . . . . . . . . . . . . . . . . . . . .192.5.3 Change a T emplate in Progress . . . . . . . . . . . . . . . .192.5.4 Mem b er Drop out . . . . . . . . . . . . . . . . . . . . . . .20 vi

PAGE 6

2.5.5 Managing the Arc hiv e . . . . . . . . . . . . . . . . . . . . . 21 2.5.6 Commen ts . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3 SYSTEM REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . 22 3.1 Denitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2 F unctional Requiremen ts . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.1 V oting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.2 V oting Metho ds . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.3 T yp es of V oters . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.4 Rep ort T yp es . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.5 T yp es of Rep ort Recipien ts . . . . . . . . . . . . . . . . . . 28 3.2.6 Time Constrain ts . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.7 Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.8 Arc hiv e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3 In teraction with Other DCS Services . . . . . . . . . . . . . . . . 32 3.3.1 Access Con trol Services . . . . . . . . . . . . . . . . . . . . 32 3.3.2 Notication Services . . . . . . . . . . . . . . . . . . . . . . 33 3.3.3 Database Services . . . . . . . . . . . . . . . . . . . . . . . 33 3.3.4 Conference Con trol Services . . . . . . . . . . . . . . . . . 34 3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4 DESIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.1 In tro duction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.2 Data Storage in Decision Supp ort Services . . . . . . . . . . . . . 35 4.3 Decision Supp ort Services Arc hitecture . . . . . . . . . . . . . . . 35 4.3.1 V oteInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.2 Rep ort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3.3 Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.3.4 V otes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.3.5 GlobalV oteInfo . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.3.6 GlobalV otes . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3.7 GlobalMem b er . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3.8 T emplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3.9 A CST emplate . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.3.10 Arc hiv e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.11 Arc hiv eChoice . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.12 Arc hiv e Mem b er . . . . . . . . . . . . . . . . . . . . . . . . 44 4.3.13 Request Manager . . . . . . . . . . . . . . . . . . . . . . . 44 4.3.14 Deadline Monitor . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.15 V oteManager . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.16 Rep ort Manager . . . . . . . . . . . . . . . . . . . . . . . . 48 4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 vii

PAGE 7

5 IMPLEMENT A TION AND TESTING . . . . . . . . . . . . . . . . . . . 50 5.1 Implemen tation Of DSS . . . . . . . . . . . . . . . . . . . . . . . 50 5.2 In terface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.2.1 Application Programmer's In terface . . . . . . . . . . . . . 51 5.2.2 User In terface . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.3 In teraction with Other Services . . . . . . . . . . . . . . . . . . . 54 5.3.1 Conference Con trol Services . . . . . . . . . . . . . . . . . 54 5.3.2 Database Services . . . . . . . . . . . . . . . . . . . . . . . 55 5.3.3 Access Con trol Services . . . . . . . . . . . . . . . . . . . 55 5.3.4 Notication Services . . . . . . . . . . . . . . . . . . . . . . 56 5.4 T esting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.4.1 Unit T esting . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6 CONCLUSION AND FUTURE W ORK . . . . . . . . . . . . . . . . . . 60 6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.2 F uture W ork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.2.1 More Sophisticated V oting Metho ds and Issue Handling . . 61 6.2.2 Iterativ e V oting Metho ds . . . . . . . . . . . . . . . . . . . 62 6.2.3 More Sophisticated Decision Supp ort . . . . . . . . . . . . 62 6.2.4 Garbage Collection of Arc hiv e . . . . . . . . . . . . . . . . 62 6.2.5 W orkro w Mo dels and Decision Mo deling . . . . . . . . . . 62 APPENDIX SOME ADDITIONAL INF ORMA TION . . . . . . . . . . . . . 63 REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 BIOGRAPHICAL SKETCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 viii

PAGE 8

LIST OF T ABLES T able page 4.1 Recipien t T yp es Managed By DSS . . . . . . . . . . . . . . . . . . . . 38 4.2 Rep ort T yp es Managed By DSS . . . . . . . . . . . . . . . . . . . . . 38 4.3 V oter T yp es Managed By DSS . . . . . . . . . . . . . . . . . . . . . . 41 4.4 Status t yp es Managed By DSS . . . . . . . . . . . . . . . . . . . . . . 46 5.1 In teraction with CCS . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2 In teraction with A CS . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 ix

PAGE 9

LIST OF FIGURES Figure page 1.1 DCS System Arc hitecture . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1 Decision Supp ort Services Arc hitecture . . . . . . . . . . . . . . . . . 36 5.1 Main Windo w of DSS . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 x

PAGE 10

Abstract of Thesis Presen ted to the Graduate Sc ho ol of the Univ ersit y of Florida in P artial F ulllmen t of the Requiremen ts for the Degree of Master Of Science DECISION SUPPOR T SER VICES F OR DISTRIBUTED CONFERENCING SYSTEM By Aparna Kak arparti Decem b er 2002 Chair: Ric hard E Newman Ma jor Departmen t: Computer and Information Sciences and Engineering Decision supp ort system (DSS) is a computer-based system that facilitates the solutions of problems b y a group of p eople who ha v e a join t resp onsibilit y to reac h decisions. V oting mec hanism is one of the to ols of DSS. The Distributed Conferencing System at the Univ ersit y of Florida is a distributed pac k age pro viding real-time supp ort for co op erativ e w ork. This w ork presen ts the decision supp ort system for Distributed Conferencing System (DCS) v.2. The DSS dev elop ed is a rexible and friendly system that allo ws p eople to initiate, terminate and participate in a decision pro cess within the con text of a conference. It pro vides on-line v oting and has an automated v ote collection mec hanism. It allo ws mem b ers curren tly not logged on to the conference to b e the v oters in a decision pro cess. It pro vides rexibilit y to the user to set time constrain ts on a decision pro cess. It also supp orts rexible automated rep orting. The system pro vides the users with dieren t v oting metho ds lik e Ma jorit y , Pluralit y , Ranking, etc. The system allo ws the users to sa v e their requiremen ts as templates, whic h can b e reused in future. These templates can b e used b y other mem b ers of the conference dep ending on their access righ ts. xi

PAGE 11

The system also handles sev eral issues that come up during a decision pro cess lik e c hange of v ote and mem b er drop outs and pro vides sev eral features lik e short circuit ev aluation, arc hiv al storage and withdra w al that add more rexibilit y to the system. Moreo v er, the system pro vides a friendly user in terface and an API that allo w conference services a means to p erform the decision-making pro cesses for conference con trol activities. The in terface allo ws b oth the users as w ell as other services of the system to initiate, participate, and query a decision pro cess. xii

PAGE 12

CHAPTER 1 INTR ODUCTION 1.1 Distributed Conferencing System Distributed Conferencing System v ersion 2 (DCS v2) is a distributed system designed to supp ort conferencing o v er wide area net w orks (W ANs). This system allo ws geographically separate users to collab orate in preparation of do cumen ts, graphics, soft w are to ols, as w ell as demonstrations. It is a pac k age that pro vides infrastructure for real time collab orativ e w ork. An o v erview of the functionalities of all mo dules of DCS is pro vided b elo w. 1.1.1 Conference Con trol Subsystem This subsystem is resp onsible for creation pro cess or b o ot up of DCS. It is resp onsible for initializing other mo dules, creating conferences, users, merging conferences, deleting conferences, deleting users, pro viding a graphical user in terface (GUI), etc. 1.1.2 Database Subsystem This subsystem pro vides database services for DCS. In this subsystem a distributed database has b een implemen ted. In tegrit y and consistency of distributed database are the main considerations for this subsystem. 1.1.3 Comm unication Subsystem This subsystem pro vides reliable causal m ulticast in a conference. All the commands from one host are executed in an order at all sites participating in that conference. It tak es in to consideration the dynamic needs for the size of the m ulticast groups, and loss of messages in the net w ork. 1

PAGE 13

2 1.1.4 Access Con trol Subsystem This subsystem deals with access con trol of issues for the conference. Users in DCS are b ound to dieren t roles. Eac h role has dieren t capabilities. This subsystem main tains an access con trol matrix to facilitate access decisions. 1.1.5 Notication Subsystem This subsystem is resp onsible for notifying users of ev en ts (e.g., a user logs in, logsout, joins a conference, lea v es a conference, etc.) using means lik e email, zwrite, mailb o x to a user or group of users who are in terested in the particular ev en t. 1.1.6 Decision Supp ort Subsystem This subsystem pro vides templates for making decisions ab out pro viding capabilities to a user. Once a decision is made it noties access con trol subsystem. Decision making encompasses issues lik e what should b e a quorum, what should b e v oting metho ds, ho w long should a v ote b e activ e, who should b e notied of the decision reac hed, etc. 1.1.7 Secure Comm unication Subsystem Secure comm unications is resp onsible for authen tication of users, creation of k eys and certicates and pro viding secure comm unication c hannels. These all mo dules in teract and comm unicate with eac h other as sho wn in Figure 1.1. In this v ersion of DCS all the services ha v e b een implemen ted in mac hine indep enden t language (JA V A), whic h will help in in tegration and p ortabilit y of these mo dules on v arious platforms. This thesis concen trates on Decision Supp ort Services. 1.2 Group w are and Computer-Supp orted Co op erativ e W ork The rapid gro wth and ev olution of information and the new p oten tials for comm unication b et w een p eople ha v e b een of great imp ortance to the success of most organizations. The k ey asp ects w ere the increased a v ailabilit y of computer net w orks and the trend to w ards team w ork. Activities in computer supp ort for

PAGE 14

3 NTF ACS DSS CCS Local Database Distr. Database Group MulticastSite Messaging Secure Messaging Crypto RMI TCP UDP JDBCDBMS A A DFS MACE, A/V sharing, Whiteboard Applications Figure 1.1: DCS System Arc hitecture team w ork are kno wn b y the notions of group w are or computer-supp orted coop erativ e w ork (CSCW). Group w are can b e dened as \computer-based systems that supp ort groups of p eople engaged in a common task or goal and that pro vide an in terface to a shared en vironmen t" [1 ]. While group w are refers to real computerbased systems, the notion CSCW means the study of to ols and tec hniques of group w are as w ell as their psyc hological, so cial and organizational eects. The goal of CSCW is to study ho w p eople w ork together in b oth small groups and large organizations and ho w group w are applications can impro v e and enhance comm unication b et w een group mem b ers and co ordination inside an organization.

PAGE 15

4 The k ey issues of Computer-Supp orted Co op erativ e W ork are group a w areness, group decision making, m ulti-user in terfaces, concurrency con trol, comm unication and co-ordination within the group, shared information space and the supp ort of a heterogeneous op en en vironmen t that in tegrates existing single-user applications [2]. CSCW systems are often classied according to time and lo cation matrix. Lo cation can b e same place (face-to-face) and dieren t places (distributed) and time can b e sync hronous and async hronous. Some of the most familiar examples of group w are are electronic mail, bulletin b oards, async hronous conferencing, group sc hedulers, real-time shared applications(suc h as collab orativ e writing or dra wing), decision supp ort systems, on-line conferencing and w orkro w systems. 1.3 Decision Supp ort Systems in Group w are Applications Group decision supp ort system (GDSS) is an in teractiv e computer-based system that facilities the solution of problems b y a set of decision-mak ers w orking together as a group [2]. There are dieren t classes of decisions for whic h the GDSS ma y b e called for: strategic, op erational, planning, crisis managemen t, and routine decision-making. There are sev eral to ols that aid in the group decision-making pro cess. V oting mec hanism is one of them. V oting is a familiar concept used widely . V oting is a metho d of making a decision in whic h eac h p erson in v olv ed indicates his or her o wn c hoice, and the c hoice that most p eople supp ort is accepted. The follo wing steps are in v olv ed in v oting mec hanism. 1. Raising an issue: An issue is an imp ortan t sub ject that p eople are discussing and trying to resolv e b y expressing their opinion. 2. V oting and collection of v otes: A v ote is a c hoice made b y a particular p erson. Someone or something (Decision supp ort system) has to collect all the v otes and k eep trac k of the results. 3. Decision Making: A decision algorithm based on the group criteria is used to reac h a decision.

PAGE 16

5 4. Rep orting Result: The result obtained from decision making is sen t to the concerned p eople. 1.4 Decision Supp ort Service in Distributed Conferencing System The rst v ersion of DCS, referred to as DCS v.1, is curren tly running at the Univ ersit y of Florida. DCS v.1 pro vides a general v oting mec hanism for conference con trol activities [3]. It oers only limited supp ort for async hronous v oting. The sync hronous v oting mec hanisms do not pro vide rexibilit y to the group to express their decision pro cesses. F or example, DCS v1 supp orted a ring system of righ ts with v oting righ ts giv en to a subset of mem b ers. Ho w ev er, within a group it is often desirable to ha v e dieren t subgroups in v olv ed in dieren t issues. Exp erience with DCS v.1 rev ealed a need for more sophisticated and rexible v oting mec hanisms. One requiremen t w as for users to b e able to sp ecify time constrain ts on the decision pro cess. F or example, a user ma y w an t the nal result in another t w o da ys, so that he can pro ceed with another activit y that is dep enden t on this result. It is also desired to pro vide rexible automated rep orting to subsets of the mem b ers, with the users ha ving the option to c ho ose their rep orting st yle and recipien t groups. The rst v ersion of DCS v.2 supp orted on-line v oting as a rexible v oting mec hanism as a to ol for decision supp ort services [4]. It supp orted on-line v oting and rep orting. Ho w ev er, it supp orted only ma jorit y and passing v ote formats and pro vided less rexibilit y in querying status and forming rep ort. This thesis describ es a new er v ersion of DSS that supp orts an extensiv e range of v oting metho ds and rexible automated rep orting st yles. DSS allo ws the users to select the v oting parameters, time constrain ts, v oters, rep orting st yles, rep orting time and rep ort recipien ts for decision pro cesses. It supp orts b oth absolute and relativ e metho ds of v oting. It uses templates to store the v oting eters, whic h can b e reused without dening the parameters again and again.

PAGE 17

6 This system tak es in to accoun t user's role, w eigh t assigned to the v ote, access righ ts, etc. It has sev eral features lik e reminders, making request for status, result, rep ort, c hange of v ote, short circuit ev aluation, etc whic h add more rexibilit y to the decision pro cess. It also allo ws the other services of the system to mak e these requests. The system c hec ks the access righ ts and p ermissions of the user b efore serving an y request. DSS allo ws withdra w al and termination of activ e motions. The system allo ws sp ecication of v oter and recipien t groups b y role and b y mem b er. Dynamic binding of v oters and recipien ts is done in suc h cases. This allo ws the v oting or nal result to b e sen t only to the mem b ers b ound to the group at that time. This facilit y is v ery helpful as the system can adapt to an y c hanges in the conference. The time constrain t allo ws the users to ha v e con trol o v er when they w an t the system to mak e the decision. The system giv es the users rexibilit y to select absolute or relativ e deadlines. The system main tains an arc hiv e of all terminated, withdra wn or susp ended motions, whic h can b e used for future reference or dev elop kno wledge base, graphs etc. The system has b een dev elop ed using Ja v a, whic h ensures that the user in terface lo oks the same on all platforms. The system has a friendly user in terface, whic h allo ws the users to mak e all the requests. It allo ws the nal user to select the motions that in terest them and view their details. The decision supp ort system is rexible and exp edites the decision pro cess. It pro vides supp ort to conference related activities. It supp orts m ultiple decision pro cesses at the same time. 1.5 Organization of Thesis Chapter 2 con tains a surv ey of the system relev an t to this thesis w ork. Chapter 3 con tains the requiremen ts. Chapter 4 discusses the design in detail. Chapter 5 explains the relev an t implemen tation details and testing p erformed on the system. The last c hapter presen ts conclusions, future enhancemen ts and mo dications.

PAGE 18

CHAPTER 2 RELA TED W ORK The purp ose of this c hapter is to presen t some related w ork and explain the motiv ation for Decision Supp ort Services. Section 2.1 giv es a brief in tro duction to CSCW and Group w are. Section 2.2 giv es brief in tro duction to Group Decision Supp ort System. Section 2.3 describ es some group w are applications dev elop ed. Section 2.4 discusses the motiv ation for Decision Supp ort Services. The last section 2.5 discusses ab out v arious v oting metho ds that can b e used in a decision pro cess. It also p oin ts out the some issues that can arise during a decision pro cess along with some p ossible solutions to these issues. 2.1 CSCW and Group w are The phrase \computer-supp orted co-op erativ e w ork" w as in tended to delineate a eld of researc h fo cused on the role of the computer in group w ork [2]. CSCW lo oks at ho w groups w ork and seeks to disco v er ho w tec hnology can help them w ork. CSCW collects researc hers from a v ariet y of disciplines: computer science, cognitiv e science, psyc hology , an throp ology , managemen t information systems, and others, eac h of them con tributing a dieren t p oin t of view ab out group in teractions and ho w to supp ort group w ork [5]. Group w are is dened as computer-based systems that supp ort groups of p eople engaged in a common task and that pro vides an in terface to a shared en vironmen t [1]. The goal of group w are is to assist groups in comm unicating, in collab orating, and in co-co ordinating their activities. Some other terms used are comm unication and collab oration. Comm unication is the exc hange of information b et w een p eople. F or the successful op eration of a 7

PAGE 19

8 group, the mem b ers need to exc hange information in an ecien t w a y . Collab oration is a cornerstone of group activit y . It can b e describ ed as the act of w orking together. Eectiv e collab oration demands that p eople share information. Shared windo ws are one of the mec hanisms dev elop ed in group w are applications to share information. These group in terfaces allo w the mem b ers join tly to manipulate an ob ject and to see the c hanges made to it. The eectiv eness of comm unication and collab oration can b e enhanced if a group's activities are co ordinated. Without co-ordination group mem b ers will often engage in conricting or negativ e actions. Group w are supp orts a large n um b er of collab orativ e activities and therefore it is dicult to classify group w are. It can b e classied generally based up on notions of time and space [6]. A Group w are system can b e conceiv ed to enhance comm unication and collab oration within a real-time in teraction, or an async hronous, non real-time in teraction. These time and space considerations suggest the follo wing four categories. 1. face-to-face in teraction, meeting ro om tec hnology; 2. async hronous in teraction, for example ph ysical bulletin b oard; 3. sync hronous distributed in teractions, for example Gro v e [4], a sync hronous do cumen t editor; 4. async hronous distributed in teraction, for example e-mails; 2.2 Group Decision Supp ort System A Group Decision Supp ort System (GDSS) can b e dened as \computer-based system that facilitates the solution of problems b y a group of p eople who ha v e a join t resp onsibilit y for reac hing the decision" [7]. The primary goal of GDSS is to mak e meetings more pro ductiv e b y increasing the sp eed at whic h decisions are reac hed without reducing, and it is hop ed, enhancing the qualit y of resulting decisions. A GDSS in v olv es a group decision mak ers with access to a database, computer, decision mo del, viewing screen, and, in man y cases, a \facilitator"

PAGE 20

9 who supp orts the group's activit y and do cumen ts the group's w ork. There are sev eral GDSS aids for decision structuring. Some of suc h aids are v oting to ols and alternativ e ranking, for idea generation [4 ] or issue analysis. It is one of a broader set of c hallenges facing computer supp orted co op erativ e w ork. There are no established w a ys of classifying GDSS's. One w a y of classifying GDSS's could b e based on its functions [4]. The follo wing are the dieren t lev els of classications. Lev el-1 are basically comm unication media pro viding tec hnical features aimed at remo ving comm unication barriers. They pro vide comm unication supp ort features lik e electronic brainstorming, v oting mec hanisms etc. Lev el-2 pro vides decision mo deling and group decision tec hniques aimed at reducing uncertain t y in the group's decision pro cess. They pro vide decision mo deling or mathematical tec hniques. Lev el-3 are more lik e group exp ert systems. They are more p o w erful and can include exp ert advice in selecting and arranging the rules to b e applied during the decision making pro cess. GDSS can also b e classied based on their underlying tec hnology [4 ]. One of the most elemen tary form of GDSS is electronic b oardro om. The decision supp ort pro vided in this is limited to storage, retriev al and programming of previously prepared presen tation materials. T eleconferencing facilitates meetings b et w een groups at t w o or more lo cations. But it is more of audio or video teleconferencing rather than computer teleconferencing. Information Cen ter pro vides rexible data handling capabilities. The main fo cus of GDSS is on honing the to ols of information cen ter in to aiding sp ecially designed for decision-making b y a particular group. Decision Conference fo cuses on impro ving decision making b y groups and users structured decision pro cesses. Decision analysts aid the participan t of the conference. GDSS can also b e used for group collab oration. Group net w ork is fo cused on in teractiv e computer supp ort for small groups in geographically disp ersed but nearb y lo cations suc h as oces within a building or a building complex.

PAGE 21

10 The eld of GDSSs is as y et not w ell dev elop ed and there are div ergen t and conricting denitions of the term. It could refer to simple systems for v oting and displa y of data or to highly in tegrated systems that incorp orate v oting, mo deling, data analysis and data displa y . The comparativ ely simple GDSSs of electronic b oardro om and teleconferencing are established in use. In most cases these to ols are not designed to facilitate group decision pro cesses. Rather they facilitate they facilitate discrete asp ects of decision pro cess, suc h as displa y of data, recording of data, etc. The information cen ter and Group net w orks are also in gro wing use. 2.3 Existing Group w are Applications 2.3.1 Conferencing Systems Conferencing Systems pro vide computer supp ort for conference activities. These systems pro vide a set of to ols for the conference mem b ers to co ordinate in carrying out the conference activities. F or example, con v ersations, reac hing a consensus are some of the activities that can b e supp orted. W e discuss t w o conferencing systemsMERMAID and DCS v.1. MERMAID . MERMAID stands for Multimedia En vironmen t for Remote Multiple A ttendee In teraction Decision making. MERMAID [8] is a distributed desktop conferencing system based on group collab oration supp ort arc hitecture. The system aims at pro viding widely disp ersed group mem b ers with an en vironmen t for holding formal or informal m ultipart y conferencing. The system w as implemen ted using a clien t serv er mo del. Eac h serv er is sp ecialized in its o wn function. F ollo wing w ere some of the features. Conference Managemen t Serv er (CMS) is used to manage the progress of a conference. Conference Information Serv er (CIS) pro vides information on conferences whic h ha v e b een held, curren tly b eing held, or y et to b e held.

PAGE 22

11 Do cumen t File Serv er (DFS), whic h manages the storing, and retrieving of the conference do cumen ts. Lo cal Comm unication Serv er (LCS), whic h manages the sending and receiving of information to/from the m ulti-domain comm unication serv er. Multi-Domain Comm unication Serv er (MCS) supp orts ecien t and accurate comm unication among clien ts. V ote collection metho ds and decision to ols are not automated in MERMAID. Only activ e users can v ote on a motion in the shared windo w. Nonactiv e mem b ers cannot v ote. It is up to the initiator of the motion to man ually collect the v otes and determine the outcome. MERMAID do es not oer an y supp ort to async hronous v oting. Distributed Conferencing System, V ersion 1. DCS v.1 . DCS v.1 is a distributed pac k age pro viding real time supp ort for co op erativ e w ork [4]. DCS has b een implemen ted as a group of co op erativ e pro cesses. Cen tral Conference Serv er (CCS) pro vides co ordination b et w een and access to conferences, monitors the p erformance of Conference Managers and do es error reco v ery . The User Manager acts a dialog manager for the individual user activ e in the conference. The Application Manager in teracts with the Application Windo w and is in c harge of the comm unication b et w een the application and the CM. The conference Manager pro vides basic conference con trol. It also pro vides a discussion windo w. The to ol used to resolv e all the conference con trol activities is v oting mec hanism. It allo ws user-dened motions. It do es not supp ort time constrain t motions. It also do es not allo w the users to select dieren t com binations of v oters, rep ort recipien ts and rep ort st yles and times. The user do es not get an y input b efore he v otes.

PAGE 23

12 2.3.2 IBIS Issue based information systems (IBIS) ha v e b een dev elop ed for use on large complex design problems. They are based on the principle that the design pro cess for complex problems. They are based on the principle that the design pro cess for complex problems is fundamen tally a con v ersation among the designers in whic h they bring their resp ectiv e exp ertise and viewp oin ts to the resolutions of the design issues. The IBIS mo del fo cuses on the articulation of the k ey issues in the design problem. SIBYL: A to ol for managing Group Decision Rationale . SIBYL is based on the IBIS tec hnology . SIBYL is a system that supp orts group decision making b y represen ting and managing the qualitativ e asp ects of decision-making pro cess [9]. SIBYL consists of three parts: DRL (Decision Represen tation language), a set of services that pro vides qualitativ e decision supp ort b y using what is represen ted in DRL, and the user in terface that mak es it easier for p eople to use DRL. SIBYL uses the kno wledge con tributed b y p eople to construct a kno wledge base represen ted b y decision graph. A decision matrix is the in terface b et w een the user and SIBYL. It consists of goals and alternativ es. It is up dated to rerect an y new kno wledge. SIBYL pro vides four kinds of services: the managemen t of dep endencies, plausibilities, viewp oin ts and preceden ts. Dep endency managemen t is resp onsible for main taining a consisten t state of kno wledge base when a c hange is in tro duced. Plausibilit y managemen t is resp onsible for main taining the consistency among the plausibilities of related claims. A viewp oin t represen ts an ob ject that represen ts a collection of ob jects that share certain assumptions. Viewp oin t managemen t is resp onsible for creating, storing, retrieving, mapping and merging viewp oin ts. Preceden t managemen t helps kno wledge sharing across groups. SIBYL tries to ev aluate the actual delib eration pro cess of the user. DRL represen ts the

PAGE 24

13 rationale. SIBYL uses a complex structure, i.e. t yp e sp ecic attributes, explicit represen tation of goals, relations b eing rst class ob jects to represen t the kno wledge base. The users use the complex decision matrix of SIBYL to reac h a decision. The decision is m utually arriv ed b y the users. SIBYL has no supp ort for v oting mec hanisms and it do es not tak e the user's input and nd out the result. Also, the consistency of the kno wledge base of SIBYL across m ultiple sites dep ends on the order in whic h messages or les are read. The users using SIBYL ha v e to b e con v ersan t with DRL and the complex decision graphs and decision matrix. Decision-making is time consuming this w a y . gIBIS: A Hyp ertext T o ol for Exploratory P olicy Discussion . gIBIS supp orts the collab orativ e construction of IBIS (Issue Based Information Systems) net w orks b y an y n um b er of co-op erating team mem b ers spread across a lo cal area net w ork [1]. The goal of gIBIS is to capture the design rationale: \the design problems, alternativ e resolutions, trade analysis b et w een these alternativ e and the ten tativ e and rm commitmen ts that w ere made in the pro cess of the decision making pro cess." gIBIS ac hiev es its goal b y pro viding a language whose v o cabulary consists of ob jects and relations generic to a certain t yp e of task, namely decision whic h in v olv e ev aluating alternativ es through argumen ts. gIBIS is mainly a h yp ertext system whose services fo cus on the presen tation of structure with the purp ose of making it easy for the p eople to see the structure of what is represen ted and en ter additional pieces of kno wledge. The gIBIS in terface consists of a graphical bro wser that pro vides a visual presen tation of the IBIS graph structure, no des and their in terconnecting links, a no de index windo w that pro vides an ordered, hierarc hical view of the no des in the curren t IBIS net w ork and a con trol panel whic h is comp osed of a set of buttons whic h extend the to ol's functionalit y b ey ond simple no des and link creation. gIBIS uses a relational DBMS as its storage manager to pro vide concurrency con trol,

PAGE 25

14 record lev el lo c king and reliable data storage. Ho w ev er, all the ob jects, whic h the issue net w orks, reference need to reside within the DBMS causing an additional constrain t. Ob jectiv es are only implicitly represen ted in gIBIS. Sometimes the relationships b et w een the ob jectiv es are not clear. So, p eople ma y nd it dicult to come to a consensus with the help of gIBIS. gIBIS is useful for large, complex design problems. It uses a complex structure that is not natural to the user. It only aids the user in reac hing the decision and do es not actually mak e the decision for the user. It is v ery time consuming. 2.3.3 Electronic Meeting Systems Electronic meeting system (EMS) is an information tec hnology (IT)-based en vironmen t designed to supp ort group meetings [5]. These en vironmen ts can include distributed facilities, computer hardw are and soft w are, audio and video tec hnology , pro cedures, metho dologies, facilitation and applicable group data. Univ ersit y of Arizona conducted some researc h and came up with Group Systems [10] . The Group Systems concept is to reduce or to eliminate the dysfunctions of the group in teraction, so that a group reac hes or exceeds its task p oten tial. The Group Systems facilities include participan t w ork area (i.e., tables or desks) arranged to pro vide a cen tral fo cus at the fron t of the ro om. Eac h participan t is pro vided with a separate net w ork ed, hard disk-based, color graphics micro computer w orkstation that is recessed in to the w ork area. One large screen video displa y is pro vided as an electronic blac kb oard. Group Systems to ols are used to deliv er a pro cess related structure to a meeting phase. There are three distinct st yles of meeting pro cess. In a c haueured pro cess, only one p erson, either a group mem b er or facilitator, uses the EMS. Group mem b er v erbally pro vides information to the \c haueur." In a supp orted pro cess, groups use b oth electronic and v erbal comm unication. In an in teractiv e pro cess, the electronic comm unication

PAGE 26

15 c hannel pro vided b y the EMS is used for almost all group comm unication; virtually no v erbal comm unication o ccurs. Group Systems pro vides supp ort for the follo wing: Idea generation: Tw o Group Systems to ols for idea-generation that use an in teractiv e pro cess. Electronic Brainstorming (EBS) pro vides an in teractiv e pro cess in whic h participan ts en ter commen ts in to man y separate discussions con tained in separate les that are randomly shared throughout the group. T opic Commen ter (TC) also uses an in teractiv e pro cess for group ideageneration; ho w ev er, commen ts are collected from meeting participan ts using a task-sp ecic structure. Idea syn thesis: The purp ose of idea syn thesis is to iden tify , syn thesize, form ulate and consolidate ideas, prop osals or alternativ es that ha v e b een discussed in an idea generation to ol. Using Group Systems to ol Idea Organizer (IO), eac h participan t w orks separately to create a priv ate list of idea categories, whic h are submitted to the group. Users are instructed to bro wse the prior EBS commen ts and dev elop general idea categories. Prioritizing: There are a v ariet y of prioritizing metho ds a v ailable in the V ote Selection to ol (e.g. m ultiple c hose, 10-p oin t rating or ranking in order), whic h emplo y an in teractiv e pro cess to collect v otes, follo w ed b y a c haueured pro cess to discuss the results. A second to ol, Alternativ e Ev aluator (AE) is a m ulti-criteria decision making to ol that uses a similar in teractiv e/c haueured set of pro cesses. A Stak eholder Iden tication and Assumption Surfacing to ol: This to ol is to supp ort systematic ev aluation for the implication of a prop osed p olicy or plan. Stak eholder's assumptions are iden tied, scaled and graphically analyzed [15]. Session planning and managemen t: The primary purp ose of this is to establish a rational meeting agenda, to facilitate the follo wing of this agenda during the meeting and to organize p ost-meeting activities. A GroupSystems to ol, Session Manager (SM), is used to supp ort these activities. Meeting facilitation: The meeting facilitator in GroupSystems pro vides tec hnical supp ort for using the en vironmen t, pro vides group dynamics supp ort, assists in meeting agenda planning, and in on-going organizational settings, pro vides organizational con tin uit y b y setting standards for system use, training and system main tenance. During the meeting the facilitator is paramoun t in ensuring that a group follo ws their agenda. The v oting to ols supp orted b y GroupSystems are not rexible. They do not pro vide supp ort for dieren t v oters for dieren t decision pro cesses. They are prioritizing

PAGE 27

16 to ols and do not supp ort other absolute decision rules lik e simple ma jorit y , passing v ote, etc. Also, there is no supp ort for non-anon ymous v oting. 2.4 Motiv ation for Decision Supp ort Services As seen from the discussion ab o v e, group w ork requires mem b er to collab orate with eac h other and collectiv ely reac h a decision on issues, for whic h they ha v e a join t resp onsibilit y . Decision Supp ort Systems aid in the decision making pro cess of the group. Conferencing systems that w ere ev aluated do not pro vide an y rexible decision supp ort services. MERMAID do es not supp ort an y automated v oting to ols. Someone has to man ually collect the v otes and determine the outcome. DCS v.1 do es not supp ort rexible v oting mec hanisms. It do es not pro vide the users the rexibilit y to c ho ose the rep orting st yles, rep orting times, v oters, etc. It do es not supp ort async hronous v oting or time-constrained motions. Group Systems do not pro vide rexible v oting to ols. They pro vide only prioritizing to ols. Apart from these there are system called the Issue Based Information Systems lik e SIBYL [9], whic h are useful for complex problems. But the users ha v e to b e con v ersan t with the language that they use. They ha v e v ery complex structure to represen t their kno wledge base. They ha v e no supp ort for v oting mec hanisms. Hence w e see that there is a strong requiremen t for a rexible v oting mec hanism that w ould allo w users to participate in a decision pro cess async hronously . The system should allo w a user to v ote ev en if they are not activ e at the time of initiation of the motion or decision pro cess. This thesis aims at dev eloping a rexible and automatic v oting, rep orting and decision making system to pro vide the decision supp ort services to the Univ ersit y of Florida Distributed Conferencing System.

PAGE 28

17 2.5 Issues in a Decision pro cess There are sev eral other issues that need to b e considered in a decision pro cess. This section discusses some of the in teresting issues that can arise during a decision pro cess along with some p ossible solutions to them. 2.5.1 V oting Metho ds This section discusses v arious v oting metho ds that can b e used for a decision pro cess. It also discusses the v arious dra wbac ks and adv an tages of the metho ds. 1. Simple ma jorit yIn this metho d the winner needs to get ma jorit y of the v otes. The mem b ers can sa y YES, NO or abstain. The problem with this metho d is that there migh t not b e an y candidate with the ma jorit y v ote. 2. W eigh ted In this metho d eac h v ote is assigned a w eigh t. A t the end of the motion the pro duct of the w eigh t and v ote coun ts to w ards the total v otes for a c hoice. This giv es rise to the issue of deciding the w eigh ts. The w eigh ts can decided based on the p osition the mem b er holds or the role b ound to at the time of v oting. Other rules of deciding the w eigh ts can b e designed according to the system. 3. Hierarc hical In this metho d the mem b ers lo w er in the hierarc h y cannot v ote un til the mem b ers holding higher ranks v ote. This is a sequen tial metho d and tak es longer time. Another feature of this metho d is, carrying of the history can b e added. The history of the motion, whic h includes the v oting pattern un til then, is also sen t to the mem b er along with the motion information. Hence the mem b er do es not ha v e to mak e a request of the rep ort. 4. Pluralit y Metho dThe candidate with the most rst place v otes wins. The winner do es NOT ha v e to receiv e a ma jorit y of the rst place v otes!. 5. Pluralit y with Elimination-It is carried out in rounds. After eac h round of v oting the candidate (or alternativ e) with the few est rst place v otes is eliminated and a new round of v oting is done with the remaining candidates. When only t w o candidates remain in a round, the candidate with the most v otes wins the election. F or an N candidate election, the Metho d of Pluralit y with Elimination requires N-1 rounds. 6. P air wise ComparisonsIn this metho d eac h candidate (or alternativ e) is matc hed head-to-head (one-on-one) with eac h of the other candidates [11 ]. Eac h candidate (alternativ e) gets 1 p oin t for a one-on-one win and a half a p oin t for a tie. The candidate (alternativ e) with the most total p oin ts is the winner.

PAGE 29

18 7. Appro v al V otingis a v oting pro cedure in whic h v oters can v ote for as man y candidates as they wish [12 ]. Eac h candidate appro v ed of receiv es one v ote and the candidate with the most v otes wins. Unlik e more complicated ranking systems, Appro v al V oting is simple for v oters to understand and use. In an election using Appro v al V oting, adding or remo ving candidates or alternativ es do es not c hange the p oin t totals of the other candidates or alternativ es.(If candidates/alternativ es drop out, simply remo v e them from the list. If candidates/alternativ es are added, v ote totals for the original candidates/alternativ es sta y the same and v oters only ha v e to giv e their appro v al or disappro v al of the candidates/alternativ es that w ere added.) 8. RankingRanking is forcing a linear order on all candidates/issues. It considers candidates relativ e to eac h other, than some absolute scale. In this metho d the v oter ranks all the c hoices giv en to him. This metho d can b e used to select m ultiple candidates. This can b e done in a single round or m ultiple rounds. Using a single round the v oters rank all the c hoices in his order of preference(Extended Ranking). The initiator decides the scale while initiating the motion. Using m ultiple rounds(Recursiv e Ranking) the v oter v otes for his/her rst preference in the rst round. The candidate with the maxim um v otes wins and the next round pro ceeds with all the earlier c hoices except the winner in the rst round. This pro cess con tin ues un til the required n um b er of candidates is selected. The ranking can also b e criterion-based. The v oters can rank eac h criterion and the decision is made b y com bining all the criteria results for eac h candidate. 9. RatingIn this metho d the v oter m ust rate the candidates/issue in some range. The v oter should b e pro vided with the range and he/she can rate with in the range. The v oter can b e optionally restricted to rate in particular v alues (only in tegers and not allo w decimal v alues). Ev ery time the v oter rates, the system should c hec k if the rating is in the range decided. The deciding function can b e median, a v erage, mean max-min, standard deviation, coun t ab o v e a threshold, etc. 10. P oin t DistributionIn this metho d eac h v oter should b e giv en some n um b ers of p oin ts to distribute among candidates/issues in v ote. F or example v oter is giv en M v otes and there are N candidates, then the v oter should b e able to giv e all the M p oin ts to a single candidate or distribute it uniformly among the N candidates.There can b e dieren t n um b er of p oin ts giv en to dieren t v oters, whic h is decided b y the initiator. P oin t distribution can mo del resourcecon tribution v oting metho ds where the p oin ts represen t, for example dollars con tributed to an eort. 11. Single T ransferable V oting-V otes are cast b y putting a \1" in the column next to the v oter's preferred candidate, a \2" b eside their second fa v orite candidate and so on un til they no longer wish to express a preference. A

PAGE 30

19 quota is calculated whic h sets the n um b er of v otes a candidate m ust attain to b e elected. V otes are coun ted according to the rst preferences and an y candidates who ha v e ac hiev ed the quota are elected. T o decide whic h of the remaining candidates are elected the v otes are transferred from candidates who ha v e more than the necessary n um b er to ac hiev e the quota and from the candidate with the least n um b er of v otes. This means that where the rst preferences of the v oters could not b e used to elect a candidate, their second preferences come in to pla y . This pro cess of transferring v otes con tin ues un til the required n um b er of candidates has attained enough v otes to b e elected. The results for the ab o v e metho ds could include nal result, statistical information lik e mean, median etc, displa y of the issues/candidates in some order dep ending on the n um b er of v otes receiv ed, detailed v oting pattern sho wing the v ote of eac h v oter. The metho ds in v olving rating or ranking results can include a displa y of a v erage rank, a v erage rate and the spread of the ranking giv en to a candidate/issue b y all the v oters p er criterion or com bined. So if there is a wide dierence of opinion among the mem b ers, the initiator should b e able to reop en discussion and tak e a rev ote on the issue. The amoun t or detail of information sen t to a mem b er dep ends on the rep orting st yle c hosen b y the initiator. 2.5.2 Tie Resolution The system should b e able to handle the situations of tie in a v oting pro cess. F ollo wing some w a ys to resolv e a tie. 1. If the v oting metho d is a m ultistage v oting, then the scores in the earlier rounds can b e used to decide. 2. The v oters who had v oted for the lo w er v oted options can b e ask ed to v ote again for the c hoices in tie. If there are c hances of a tie again, the system can ask some n um b er of v oters to rev ote. The n um b er can b e calculated and mem b ers pic k ed at random. 3. The v ote of the c hairman or some senior mem b er can decide the result. 2.5.3 Change a T emplate in Progress There ma y b e cases when a request to c hange a template is receiv ed. The template cannot b e deleted b ecause there can b e some motions curren tly using the template. This request can b e handled in follo wing w a ys.

PAGE 31

20 1. No concurrency -One solution should b e to not allo w a template to b e edited while an y motion using it is in progress. This metho d will not allo w an y discrepancies but could lead to dela ys or deadlo c k, as one motion cannot b e started un til another motion is completed. 2. Snapshot and F reeze-Another solution w ould b e to tak e a snapshot of the template at the b eginning of the motion. So ev en if there is an y c hange to the template some time it do es not aect the motions already started but the motions receiv ed after this c hange will use the new template. 3. Dynamic Ev aluationThe initiators of all the motions using the templates should b e informed and the initiator should decide if he w an ts to include the c hanges to the template or con tin ue with the old v ersion. 2.5.4 Mem b er Drop out It is p ossible that a mem b er migh t lea v e the conference when a decision pro cess is in progress. P ossible Solutions include: 1. Restart motion; 2. Discard the mem b er's v otes; 3. Coun t v ote on tie; 4. Single T ransferable V ote; 5. Appro v al v oting; 6. Inform initiator; Using v oting metho ds lik e appro v al v oting the v oting is not aected ev en if a memb er lea v es the conference. Another solution w ould b e to inform all the initiators of the motions for whic h the mem b er dropping out of conference w as mem b er. The initiators can c hange the v oting metho d or some parameter accordingly . If the mem b er lea ving the conference is a candidate in motion, his/her v otes can b e distributed among the other candidates using metho ds lik e single transferable v ote, etc. The decision to include the mem b er's v ote can b e made after c hec king if a decision can b e reac hed without considering the mem b er's v ote. The system can

PAGE 32

21 consider the v ote only if there is a deadlo c k or tie and including this v ote can break the tie. 2.5.5 Managing the Arc hiv e The Arc hiv e could b e used to store all/subset of the terminated motions. This will allo w access to the motion information in the future. Ho w ev er the data will ha v e to b e compressed or remo v ed from the Arc hiv e after some in terv als or the size of the arc hiv e can b ecome unmanageable. This can b e called \Garbage Collection of Arc hiv e". P ossible options for Garbage Collection are as follo ws. 1. Remo v e the data after xed in terv als. 2. Conduct v oting on whic h issues need to b e deleted. This is not advisable as it could lead to further o v ercro wding of the Request or Issue table. 3. Keep only a xed n um b er of en tries in the arc hiv e table and if the n um b er is reac hed the oldest issues are deleted. 4. Keep a xed n um b er of en tries or issues of eac h t yp e. 5. Create another application to decide the lifetime of motions in Arc hiv e. This application can b e generic or sp ecically designed based on the particular conference's p olicies. 2.5.6 Commen ts V oting metho ds lik e Ma jorit y and Ma jorit yNegativ e can b e used for binary motions (motions with one c hoice/issue and P ass/F ail outcome). The other metho ds can b e used for single or m ultiple candidate selection. Metho ds lik e ranking, rating, etc. can b e used to select \k" candidates from the \n" con testing candidates. These metho ds can b e used to get the top `k' candidates, middle \k" or all candidates excluding the \k" lo w est v oted candidate. Also decision pro cesses or v oting metho ds can b e designed that incorp orates and allo w use these v oting metho ds. F or example there could b e m ulti-round decision pro cesses that use rating or ranking at ev ery stage to eliminate or select candidates for next round.

PAGE 33

CHAPTER 3 SYSTEM REQUIREMENTS This c hapter explains the requiremen ts for decision supp ort services in DCSv.2. The c hapter is divided in to three sections, the rst section denes the terms that are used in subsequen t sections, the second section explains the functional requiremen ts of the system and the last section explains the in teraction of the mo dule with other mo dules of the system. The main function of Distributed Conferencing System (DCS) is to supp ortdistributed conferences, distributed applications and div erse distributed activities o v er a Wide Area Net w ork (W AN). DCS v.2 w as conceiv ed to pro vide a broader functionalit y and supp ort than w as pro vided in DCS v.1. DSS in DCS v.2 can b e categorized as group w are that assists co op erativ e w ork among remote mem b ers of a conference b y pro viding services that enable them to comm unicate and mak e decisions. 3.1 Denitions Some denitions of the terms used in this do cumen t are giv en b elo w. 1. DCS Domain constitutes the single instan tiation of DCS that ma y co v er dieren t administrativ e domains and manage m ultiple conferences. 2. Administrativ e Domain is a set of resources under a single administration. 3. Sub ject is an y user pro cess running in the system. 4. Ob jects are the class of passiv e (i.e. non-activ e) en tities that can b e acted up on b y sub jects. Ob jects can con tain, and b e con tained b y other ob jects (i.e. ob jects ma y b e non-atomic). 5. Conference is a tuple consisting of mem b ers, ob jects, application, roles (non-n ull) , allo w able mem b er-role bindings, decision templates and v ote status. 22

PAGE 34

23 6. Roles are lab eled set of privileges, whic h ma y b e b ound to a sub ject. A sub ject has no privileges unless b ound to a role. 7. Mem b er of a conference is a DCS user that is allo w ed to bind his sub ject to a role within that conference. 8. Applications are the class of en tities that a sub ject can use to act up on an ob ject (i.e. an en tit y that pro cesses ob jects). Sub jects use applications up on ob jects. 9. Activ e Mem b er is a mem b er who has an instan tiated sub ject, whic h is b ound to a role in a conference. 10. User's Home Domain is the administrativ e domain where the user dened his accoun t. 11. Motion in a conference is a formal prop osal, whic h a subset of mem b ers of the conference ha v e to v ote on. The terms Motion and Issue are used in terc hangeably in this do cumen t. 12. T emplate is an ob ject that has the attributes of a v oting pro cess. 13. A ttributes are the prop erties and mem b er elds of a template. 14. Arc hiv e is a collection of the previous committed motions. 15. P ending Motion is a motion, whic h has not b een v oted on b y the mem b er. 16. Activ e Motion is a motion that is in progress in the conference. 17. V oting is a metho d of making a decision in whic h eac h p erson or the required p eople indicate his or her c hoice and the c hoice whic h most p eople supp ort is accepted. The steps in v olv ed in a v oting pro cess are:Raising a motion, v oting and collection of v otes, decision-making, storing and rep orting results. 18. Raise an Issue is to put forw ard an issue for decision b efore the mem b ers of conference. 19. Decision-making is the algorithm based on the group's criteria whic h is used to reac h a decision. 3.2 F unctional Requiremen ts DSS is a computer-based system that facilitates the solutions of problems b y a group of p eople who ha v e a join t resp onsibilit y of reac hing the decision. It

PAGE 35

24 pro vides supp ort for users to in teract with one another on issues that require a group decision. The in ten t of DSS is to pro vide automated means of gathering the opinions of some subset of the mem b ers of a conference, pro cessing it and pro viding the results either to a dieren t or the same subset of mem b ers, subsystems or applications. DSS uses its v oting mec hanism as one of the to ols to ac hiev e this end. This system m ust b e a rexible and friendly system that allo ws p eople to initiate, participate or terminate decision pro cess, in a conference. It should pro vide on-line v oting and ha v e an automated v ote collection and notication mec hanism. It should allo w mem b ers not activ e in a conference when a motion is made to b e eligible to abstain and receiv e results of a decision pro cess. Th us it is necessary to giv e rexibilit y to the user to select time constrain ts on a decision pro cess and to supp ort automated rep orting. The system m ust pro vide v arious v oting metho ds, v oter groups, recipien t groups, rep orting st yles and an in terface that allo ws users to initiate and participate in the decision making pro cess. It should k eep record of the motions after their termination for future reference or mo deling b y decision graphs etc. Main functions of DSS can b e classied as: 1. Conducting v otes, pro cessing them and storing the results; 2. Arc hiving the results; 3. In terface with other DCS services lik e Access Con trol and Notication Services; 4. Pro viding user in terface to use the DSS; 5. Handle the issues and c hanges that arise during a decision pro cess; As men tioned, DSS uses the v oting mec hanism to pro vide decision supp ort. The main resp onsibilit y of DSS w ould b e to start motions, collect v otes and

PAGE 36

25 store them, pro cess the v otes, mak e decision and send the rep ort. The terminated/withdra wn motion information is arc hiv ed for future use. These features uses of DSS can b e utilized using the in terface pro vided b y DSS in form of user in terface and APIs. The API can b e used b y the other mo dules and applications (refer 6.2) of DCS. Apart from these, DSS also has to handle issues that arise in a conference due to its dynamic nature, e.g. mem b er and initiator drop outs, withdra w als, etc. This c hapter will discuss in detail ab out the features pro vided b y DSS. 3.2.1 V oting This section describ es the dieren t v oting metho ds, v oter groups, recipien t groups and rep orting st yles that m ust b e supp orted and the facilities to sp ecify the time constrain ts. It also discusses the other issues that can come up during a decision pro cess. V oting is the to ol used b y DCS v.2 to arriv e at a decision on an issue or motion. DSS should p erform the ab o v e functions and allo w the user to select the t yp e of v oting pro cess. The v oting pro cess m ust start when there is request from a user or another subsystem (e.g., A CS) to start a motion. The DSS should pro vide an in terface to the user to giv e his requiremen ts and select the v oting and rep orting pro cedure for the motion. After the initiator mak es the selection and giv es the details, a Motion Num b er should b e returned to the user/service. The user can refer or enquire ab out the motion using the motion n um b er. Motion n um b ers m ust b e unique. The system should allo w the users to dene new templates that can b e reused later in the system. This giv es user considerable rexibilit y and will b e a p o w erful to ol for group decision-making. It allo ws the user to mak e dieren t templates according to his/her requiremen ts or curren t conference p olicies. F or example, if the new p olicy of conference c hanges the p ercen tage of v otes required to pass a

PAGE 37

26 motion or the w eigh ts assigned to eac h role, it should b e p ossible to create a new template and implemen t the new p olicies. 3.2.2 V oting Metho ds The initiator of a motion m ust b e able to select an y of the follo wing v oting metho ds for his/her motion at the time of initiation. Ma jorit y and Ma jorit y with Negativ e v otes metho ds can b e used for binary decisions (issues with YES or NO decision) only . There is only one c hoice for these motion and the users can v ote \y es" or \no". The initiator of the motion sp ecies a threshold n um b er or threshold p ercen tage required for the motion to pass. A threshold n um b er/p ercen tage of v otes m ust b e obtained to result in pass. Abstains are not included in p ercen tage but are included in Quorum satisfaction. The other metho ds can b e used for candidate selection. Threshold p ercen tage option is not allo w ed for these metho ds b ecause the nal coun t dep ends on the w eigh ts or rating pro vided b y the user, not on the n um b er of v otes. 1. Ma jorit yIn this metho d the winner should get ma jorit y of the v otes. The mem b ers m ust b e able to sa y YES, NO or abstain. The p ercen tage required for the motion to pass could c hange from ma jorit y (more than 50%) to 70% or 75%. It could also b e sp ecied in terms of an absolute n um b er i.e. the minim um n um b er of v otes required to pass a motion (so there should b e the sp ecied n um b er of v otes in fa v or to win, irresp ectiv e of the n um b er of v oters participating). 2. Ma jorit y with Negativ e v otesIt is dieren t from the ab o v e metho d only in the w a y that v oters can giv e negativ e v otes to a candidate/issue they dislik e. 3. Pluralit y Metho dIn this the candidate with most rst place v otes wins. The candidate also should ha v e got the threshold n um b er of v otes. 4. W eigh tedIn this v ote eac h v ote m ust b e assigned a w eigh t. The pro duct of the w eigh t and the v ote should coun t to w ards the total v otes for the candidate. The w eigh ts can b e decided based on the role to whic h the v oter is b ound. DSS should pro vide default w eigh ts to ev ery role in the system. 5. RankingRanking is forcing a linear order on all candidates/issues. It considers candidates relativ e to eac h other, than some absolute scale. In this metho d the v oter ranks all the c hoices giv en to him. This metho d can b e used to select

PAGE 38

27 m ultiple candidates. It can b e done in a single round or m ultiple rounds. This system should allo w only single rounds. Using a single round the v oters rank all the c hoices in his/her order of preference. The n um b er of ranks allo w ed should b e equal to the n um b er of c hoices in the motion. 6. RatingIn this metho d the v oter m ust rate the candidates/issue himself within some range. The v oter should b e pro vided with some range and he can rate with in the range. The v oter migh t b e optionally restricted to rate in particular v alues (only in tegers and not allo w decimal v alues). Ev ery time the v oter rates, DSS should c hec k if the rating is in the range sp ecied. 7. P oin t DistributionIn this metho d eac h v oter should b e giv en some n um b er of p oin ts to distribute among candidates/issues in v ote. E.g. a user is giv en M v otes and there are N candidates, then the v oter should b e able to giv e all the M p oin ts to a single candidate or distribute it uniformly among the N candidates, ho w ev er the total n um b er of p oin ts that he giv es is alw a ys M. 3.2.3 T yp es of V oters The DCS user can select an y of the follo wing t yp es of v oters. 1. All mem b ersAll the mem b ers in the conference will b e eligible to v ote on the motion. 2. All Activ e mem b ersAll the mem b ers of conference activ e at a particular time or time of initiation will b e the v oters for the motion. 3. Sp ecic rolesThe user should b e able to sp ecify mem b ers b ound to sp ecic roles to b e the v oters for the motion. 4. Sp ecic mem b ersThe user should b e able to sp ecify the v oters b y giving a their Mem b erId. 5. V arious Com binations of the ab o v e t yp esThe initiator should b e able to select more than one t yp e. F or example, he can ask all activ e mem b ers b ound to sp ecic roles to v ote. 3.2.4 Rep ort T yp es Result t yp e denes the detail in whic h a mem b er receiv es the rep ort of a motion. F ollo wing are the v arious rep ort t yp es allo w ed b y DSS. 1. Result. 2. Result with Final Coun tThis will giv e the n um b er of v otes in eac h category along with the result.

PAGE 39

28 3. Result with v oting pattern (Roll call)This st yle should tell the user the whole v oting pattern i.e. ho w eac h v oter has v oted. 4. Result with Statistical InformationThis st yle includes some statistical information lik e mean, median of the motion results. The rst t yp e of rep ort just consists of the decision of the motion (P ass or fail). It should also include the winning candidate for motions with m ultiple candidates. 3.2.5 T yp es of Rep ort Recipien ts Recipien ts are the mem b ers of the conference who receiv e information ab out the result of the motion after the termination of motion. In DSS, the initiator sp ecies the recipien ts and their resp ectiv e rep ort t yp e at the time of initiation of motion.1. All mem b ers of the conference 2. All v oters 3. Sp ecic mem b ers 4. Sp ecic mem b ers b ound to certain roles 5. V arious com binations of the ab o v e t yp es The initiator should b e able to select one or more of the listed categories. The system should allo w dieren t com bination of recipien ts and rep ort t yp es. In a case where a recipien t falls in to more than one category , the mem b er should not receiv e m ultiple copies of the rep ort. F or example, a user can b e mem b er of a conference and also b e b ound to a sp ecic role that receiv es the results. Only one rep ort should b e sen t to a user. The DSS gets the required mem b er's information from Conference Services. A t the termination of the motion, a nal rep ort is created and the Notication Services (NS) is requested to notify the recipien ts.

PAGE 40

29 3.2.6 Time Constrain ts The initiator of the motion should decide the lifetime of the motion. This allo ws the initiator to set some time in terv al, i.e. the p erio d during whic h the system collects and pro cesses the v otes and at the end of whic h it mak es the decision. This in terv al can b e absolute or relativ e. The motion is terminated at the end of the time in terv al. The user should b e able to set dieren t time in terv als: 1. mon ths, 2. da ys, 3. hours, 4. min utes and 5. absolute time, for example 10/08/2002 The time should b e coun ted from the momen t the user asks the service to start. A motion should not start if the deadline is not sp ecied. Ho w ev er the system ma y not w ait for this in terv al if the initiator has c hosen the "Short Circuit" (refer 3.2.7) option. Short circuit should not w ait for all the v oters to v ote. The motion is ev aluated after eac h v ote once the quorum v ote has b een obtained on the issue. If the threshold n um b er of v otes has b een ac hiev ed, the motion is accepted and terminated. Otherwise the v oting con tin ues and v otes collected. 3.2.7 Other Issues Multiple roles . There migh t b e cases where a mem b er can bind to more than one role. A t an y instance the role to whic h the user is b ound to while logging in to the system should b e considered.

PAGE 41

30 Change of v ote . The mem b ers should b e able to c hange their v ote b efore the deadline if it is allo w ed b y the motion rules. This should b e one of the parameters sp ecied b y the initiator while initiating a motion. Mem b er drop out . It is p ossible that a mem b er migh t lea v e the conference when a decision pro cess is in progress. In the DSC v.2, if suc h a situation arises, the v ote of the mem b er should b e considered as abstained. Ho w ev er if the mem b er had already v oted for a motion b efore lea ving the conference, the v ote should b e still coun ted. Initiator drop out . If the initiator of the motion lea v es the conference the motion is canceled and the v oters and rep ort recipien ts should b e informed ab out the drop out ev en t. Withdra w a motion . A motion can b e withdra wn b efore a decision has b een reac hed on a motion. A motion can b e deleted only b y the initiator of the motion, A CS request or group decision. Requests whic h dep end on another motion's result . The DSS con tacts A CS with questions ab out p ermissions of mem b ers for sp ecic requests. The A CS can resp ond with v alues 1(p ermission gran ted), 0(p ermission denied) or start another issue to decide on the request in whic h case the issue n um b er is returned. In suc h a case the resp onse to the request has to b e deferred till the motion is decided on. F or suc h requests the details of the motion should b e logged in a le. When the decision for the motion is reac hed, all the requests dep ending on it should b e serv ed. Logging Results . After the motion the nal results and the v oting pattern of the motion is stored. Apart from sending the results to the mem b ers the results are also stored in to an Arc hiv e whic h allo ws the users to access or refer a motion in future.

PAGE 42

31 Quorum . With this option, atleast the quorum should ha v e v oted in order to mak e the decision. Hence the motions with this option should ha v e the quorum requiremen t satised along with receiving the threshold n um b er of v otes to pass. Short circuit . With this option the decision can b e reac hed b efore all the mem b ers ha v e v oted. After the quorum has v oted, whenev er the decision can b e made, the motion will b e terminated. The result could b e dieren t with short circuit option. Short circuit will not w ait for all v oters to v ote, so the v oters who ha v e abstained will not ha v e enough time to v ote again. Whereas when short circuit is not selected, they can v ote again and result could b e dieren t. Reminders . The mem b ers should b e informed ab out their p ending motions within a certain time in terv al. DSS should allo w mem b ers to select this in terv al. Hence the mem b ers do not ha v e to remem b er all the deadlines and are alerted b efore the deadline if they ha v e not cast their v ote. T emplate creation and deletion . The mem b ers should b e able to view and create and delete templates according to their requiremen ts. Ho w ev er a template cannot b e deleted if there is an y activ e motion using the template. DSS do es not supp ort cop ying and up dates to a template. Motion life . The system should ha v e the facilit y to remo v e the arc haic motions. Suc h motions can b e handled using the timeout mec hanism. If the motion is undecided till the timeout is reac hed, it is susp ended. This can b e implemen ted using a standard timeout for all the motions or making it one of the parameters of the template b eing used. In this system w e dene a standard timeout of 5 y ears. The timeout p erio d can b e c hanged b y the conference. 3.2.8 Arc hiv e The details of ev ery motion after termination are stored in the Arc hiv e table. This information could b e used to prepare mo del graphs, pro vide samples or information to the mem b ers in future. The user in terface for DSS should pro vide

PAGE 43

32 facilit y for the user to p erform a searc h on the arc hiv e. The searc h criteria can include issue n um b er, initiator id, mem b er id, deadlines, etc. Lik e ev ery other request, DSS c hec ks the mem b er's access righ ts b efore resp onding with the results. The problem that arises due to this metho d of logging results is that the size of the arc hiv e migh t b ecome unmanageable after some time. Hence there should b e some rule to remo v e the motions from the arc hiv e from time to time. This is garbage collection of the arc hiv e. In DCS v.2 there will b e another application that decides the lifetime of the motions. Also motions can b e remo v ed from the Arc hiv e when told b y the A CS. 3.3 In teraction with Other DCS Services Decision Supp ort Service in teracts with other DCS's services in t w o w a ys. 1. Oering servicesDSS should pro vide a clean in terface to other DCS services so that they can use DSS to decide on conference related motions. F or example Access Con trol Service could start a motion to decide if a new user could b e admitted to the conference. 2. Requesting servicesDSS requires information ab out the users access righ ts, their domain information, roles, etc. F ollo wing are dieren t w a ys DSS in teracts with the other mo dules. 3.3.1 Access Con trol Services DSS should resp ond to the requests and queries of A CS. It should also in teract with A CS to get p ermissions or information ab out mem b ers, motions, roles etc. The request for a v oting pro cess can come from A CS or from a user. On receiving a request for decision on a motion, the DSS should sa v e the motion with all the parameters in the required tables and return a Motion Num b er to A CS or the user using the DSS user in terface. The A CS or the initiator should b e able to mak e queries ab out that motion to DSS using this Motion Num b er. The queries include information ab out the status, result, v oters, c hoices or withdra w al. After the decision is reac hed for the motion the result should b e sen t to A CS.

PAGE 44

33 DSS should resp ond to A CS ab out the queries ab out the n um b er of activ e motions with DSS, the status of a particular motion, request for a rep ort, for the result or to cancel a motion. The DSS should approac h the A CS with questions ab out the access righ ts and p ermissions of a user. The A CS resp onds to the access righ t's queries with v alue 0 (p ermission denied), 1 (p ermission gran ted) or a n um b er that signies an issue n um b er. The third case should o ccur when the A CS initiates a motion to decide on the request. In this case DSS should log the original request in a le till the motion it is dep ending on(motion n um b er returned b y A CS)is decided. The system cannot get in to a cycle though the services call eac h other to resolv e their requests. The cycles do not arise b ecause when DSS receiv es a request to start a motion from A CS, it should p erform the request without sending bac k an y message or request to the A CS. So when A CS returns a motion n um b er in reply to a access con trol question from DSS, the original DSS request should b e logged till the second motion is decided and no request is sen t to A CS again regarding that request. Hence the cycle breaks at that p oin t. A CS v eries ev ery request receiv ed b y DSS. On receiving a request from a user, DSS should c hec k bac k with A CS if the mem b er making the request has p ermissions. The request is pro cessed dep ending on the resp onse from A CS. 3.3.2 Notication Services Notication Service should pro vide an in terface for notication of ev en ts to the mem b ers of the conference. DSS requires the NS to notify the v oters ab out the motion when its initiated, the results of the motion after it terminates, pro vide the up date or rep ort of a motion or send reminders to the mem b ers b efore deadline. 3.3.3 Database Services DSS requires databases and tables to store information ab out the decision pro cesses. Database Service should pro vide this supp ort. It should pro vide

PAGE 45

34 primitiv es to create a table and p erform other op erations lik e insertion, up dating and deletion. DSS needs these primitiv es to create its tables, store and retriev e information from it. Database Service up dates the tables at the host site and propagates the up dates to tables in the other sites. 3.3.4 Conference Con trol Services Conference Con trol Services is resp onsible for starting DSS and passing the references to the other mo dules of the conference used b y DSS. Conference Con trol Services should pro vide information ab out all the mem b ers in the conference, all the activ e mem b ers in the conference, roles in the conference and mem b ers b ound to eac h role in the conference. It also pro vides information ab out the user's name, home domain and an y mo dications to the user's role list. 3.4 Summary The purp ose of this do cumen t w as to presen t the functional requiremen ts for Decision Supp ort Services in DCS v.2. Denitions of the most frequen tly used terms ha v e b een pro vided. Decision Supp ort Services will b e used in three w a ys in DCS. It can b e used b y the other mo dules of the conference. A CS in DCS main tains a decision matrix that stores the sub ject, ob ject, access t yp e and a decision p oin ter. This design of A CS w ould require in teraction with DSS to initiate motions and use services of DSS. DSS requires the supp ort of other mo dules of DCS to get information ab out the mem b ers, roles, sites and database supp ort. DSS pro vides an API for the other mo dules to in teract DSS. The future applications of DCS can also mak e use of this API for in termediate pro cessing. DSS can also b e used b y users of conference using the user in terface of DSS.

PAGE 46

CHAPTER 4 DESIGN 4.1 In tro duction Decision Supp ort Service within DCS is seen as a single functional mo dule that pro vides services to other DCS comp onen ts and DCS users. This c hapter describ es the detailed design for Decision Supp ort Services based on the requiremen ts presen ted in the in Chapter 3. The rst section describ es the storage facilities used in DSS, and last section describ es the DSS Arc hitecture in detail. 4.2 Data Storage in Decision Supp ort Services The use of a commercial pro duct in the implemen tation of DCS v.2 will require all places in terested in running the system to install the commercial pro duct at their site. This jeopardizes the p ortabilit y and abilit y to distribute the system, whic h are among its requiremen ts. F or this reason, DSS uses the facilities pro vided b y the Database Services to store its data. 4.3 Decision Supp ort Services Arc hitecture Decision Supp ort Services is seen as a single functional mo dule that pro vides services to other DCS comp onen ts. Decison Supp ort Services is divided in to 4 mo dules and uses 11 tables. The tables are used to store the users/A CS requests (V oteInfo table), v oters and their v otes (V ote table), rep ort details (Rep ort table), c hoices (Choice table), Arc hiv e (Arc hiv e, Arc hiv eMem b er and Arc hiv eChoice tables) and to store T emplates (T emplate and A CST emplate). The rest of the tables are used to mak e this information a v ailable to other sites (GlobalV oteInfo and GlobalMem b er) as sho wn in Figure 4.1. F ollo wing are the v arious tables used b y DSS. 35

PAGE 47

36 Choice VoteInfo Votes GlobalVoteInfo GlobalMember Template Archive ArchiveMember ArchiveChoice Add\ Delete\ Retrieve Add Vote Information Retrieve\Delete Retreive\Delete Retrieve\ Delete VoteHandler VoteManager Add\Retrieve\ Delete Motion# ACS checks DSS request Info from CCS s ReportManager Report Add Retrieve\Delete Votes from User Information Flow Functional Module ACS Template Request Manager Add Add Add Add Add \ Retrieve \ Retrieve \ Retrieve \ Retrieve \ Retrieve Retrieve Delete\ GlobalVotes Add Retrieve\Delete Table Figure 4.1: Decision Supp ort Services Arc hitecture 4.3.1 V oteInfo This table k eeps detailed information ab out all the activ e motions instan tiated in that domain. All the information regarding the motion is stored in this table on initiation of a motion. This is a lo cal table and k eeps information only ab out the motions initiated at the resp ectiv e site. When a motion is initiated, a record is inserted in to the table and remo v ed when the motion is withdra wn/terminates. It stores the follo wing information: 1. IssueNum b er is a unique in teger that iden ties the motion. This v alue is returned b y the DSS to the initiator or A CS. 2. IssueTitle is a string that con tains the title of the motion.

PAGE 48

37 3. Issue is a string that describ es the motion. 4. T emplate Num b er is a unique in teger that iden ties the template b eing used b y the motion. 5. Initiator Id is a unique in teger that iden ties the DSS mem b er who initiated the motion. 6. StartDate is a date when the motion w as initiated. This is the system date and time at the time the motion w as initiated. 7. EndDate is the date that iden ties the end date sp ecied b y the initiator or the template. If the deadline is relativ e then the absolute calculated and stored in this eld. 8. WinCoun t is the coun t sp ecied b y the initiator or template that m ust b e reac hed for the motion to b e successful. 9. quorum is a in teger that iden ties the quorum requiremen t for the motion. It has a v alue 0 if the quorum option is not selected. 10. Range is a string that con tains the upp er and lo w er limits of the range allo w ed for a motion using Rating and P oin t Distribution v oting metho ds. F or other v oting t yp es it is n ull. 4.3.2 Rep ort This table k eeps record of all the recipien ts and the corresp onding rep orting st yle. There could b e situation where the initiator selects the v ote to b e sen t to a group or mem b ers who can bind to a role. The mem b ers b ound to that particular role can c hange from the time the motion w as initiated to the time it terminates. So to a v oid this static binding, the rep ort table stores the t yp e of group or role sp ecied b y the initiator. The DSS righ t no w supp orts only the groups sp ecied in T able 4.1. Apart from groups the initiator can also select to sp ecify the recipien ts b y giving the list of their Mem b erIds. The user can also select dieren t com binations of the groups men tioned. Similar to V oteInfo table, this is a lo cal table and one for ev ery domain. It has the follo wing elds: 1. IssueNum b er is a unique in teger that iden ties the motion.

PAGE 49

38 2. T yp e is a unique in teger that iden ties the role, group to whic h the rep ort should b e sen t. It can only tak e v alues presen ted in T able 4.1. 3. Mem b erId is a unique iden tier that iden ties the DSS mem b er who should get the rep ort. It is n ull if the t yp e is a role, group or A CS initiated motion. 4. Rep ortT yp e is a string that stores the t yp e of rep ort to b e sen t to the mem b er or mem b ers who can bind that role or group. The string is a concatenated list of the rep ort t yp es (in tegers). The rep ort t yp es managed b y DSS are presen ted in T able 4.2. T able 4.1: Recipien t T yp es Managed By DSS Recipien t T yp e Description All Conference Mem b ers All the mem b ers of the conference All v oters All the v oters. A CS initiated motions No recipien ts, the result is sen t bac k to A CS. Initiator sp ecied The mem b ers sp ecied at the time of initiation. Role All the mem b ers b ound to a sp ecic role. T able 4.2: Rep ort T yp es Managed By DSS Rep ort T yp e Description Result P ass or F ail. Also giv es winning c hoice if P ass Result with Num b er Result with coun t of v otes for winning c hoice Result with stat Result with statical information of v otes eg median Result with vP attern Result with v otes of eac h mem b er Result with vP attern and stat Result with statistical information and v oting pattern 4.3.3 Choice This table k eeps a list of the c hoices for the motion along with their c hoice n um b ers. It has follo wing elds: 1. IssueNum b er is an in teger that iden ties the motion . 2. Choice is a string that describ es the c hoice. 4.3.4 V otes The V otes tables store the v oter's ids and their v ote information. There is a table for eac h t yp e of v oting metho d supp orted b y the system. DSS system curren tly supp orts 7 v oting t yp es and there is a table for eac h t yp e. The tables

PAGE 50

39 that store the v ote information are Ma jorit y , Ma jorit yNeg, Pluralit y , W eigh ted, Ranking, Rating and P oin t Distribution. These tables store the v oterId and their v ote for a particular motion. A t deadline, the table to b e accessed is found from the v oting t yp e v alue and all the information ab out the v otes is obtained to mak e the decision. They hold the follo wing information: 1. IssueNum b er is an in teger that iden ties the motion. 2. Mem b erId is an in teger that iden ties the DSS mem b er. 3. V ote is an in teger whic h iden ties the v ote of the mem b er. It can tak e v alues 0 or 1 for v oting t yp e Ma jorit y and Ma jorit yNeg. F or other v oting metho ds it stores the c hoice n um b er of the c hoice selected. 4. Rate/Rank/P oin ts/W eigh tThis eld exists only in Ranking, Rating, W eigh ted and P oin tDistribution. The W eigh ted table stores the w eigh t assigned to the v ote , rating stores the rating giv en to the c hoice b y the user, Ranking stores the rank and p oin t distribution stores the p oin ts a w arded b y the user to the c hoice. 4.3.5 GlobalV oteInfo The GlobalV oteInfo table k eeps detailed information ab out all the activ e motions in the conference. It is a replicated table that resides in eac h administrativ e domain where the conference is initiated. The primary goal of GlobalV oteInfo table is to reduce the n um b er of messages among administrativ e domains. Since the information ab out all the motions of the conference is stored in this table, the domains with remote v oters will not ha v e to send messages to the host site for information regarding the motion. T o get a list of p ending motions, messages need not b e sen t to the host site. T o get the status the GlobalV oteInfo is c hec k ed at that site itself. The user can see the list of motions he is authorized to withdra w without sending a message to host site and only when he decides to withdra w, the host site is con tacted. This approac h reduces pro cessing time and net w ork trac.

PAGE 51

40 The GlobalV oteInfo table is up dated when a motion is initiated in the conference or when an activ e motion is terminated. It stores the siteId where the motion w as initiated. When a user v otes or requests for withdra w al of a motion from a remote site, the remote site can con tact the host site using the siteId and pass the information. It has the follo wing information: 1. IssueNum b er is an unique in teger that iden ties the motion. This v alue is returned b y the DSS to the initiator or A CS. 2. IssueTitle is a string that con tains the title of the issue for the motion. 3. Issue is an string that describ es the motion. 4. T emplate Num b er is an unique in teger that iden ties the template b eing used b y the motion. 5. StartDate is a date when the motion w as initiated. This the system date and time at the time the motion w as initiated. 6. EndDate is the date that iden ties the end date sp ecied b y the initiator or the template. If the deadline is relativ e then the absolute calculated and stored in this eld. 7. Initiator Id is an unique in teger that iden ties the DSS mem b er who initiated the motion. 8. Range is a string that stores the minim um and maxim um range for the ranking and rating v oting metho ds or the total p oin ts allo w ed for p oin t distribution v oting t yp e and for the rest of the v oting metho ds it is n ull. 9. Roles is a string that stores the roles allo w ed to v ote for a motion. 10. SiteId is a unique in teger that iden ties the site where the motion w as initiated. 4.3.6 GlobalV otes This table k eeps the v otes for v arious issues of the conference. Whenev er a user v otes for a motion this table is up dated along with the resp ectiv e v ote table at the host site. It allo ws the domains with remote users to sho w the p ending motions without con tacting the host site of motion. Sev eral other requests lik e motion

PAGE 52

41 status, v oting status etc can also b e serv ed without con tacting the host site. It stores the follo wing information: 1. IssueNum b er is a unique in teger that iden ties the issue. 2. Mem b erId is a unique in teger that iden ties the mem b er of conference who has cast the v ote for the motion. 3. V ote is a in teger that stores the c hoice selected b y the mem b er 4.3.7 GlobalMem b er This table k eeps information ab out the v oters of the motions. It has a list of all the v oters of a motion. The list of p ending motions for an y user can b e found from the global tables and the host site is con tacted only when the user v otes. It has the follo wing elds: 1. IssueNum b er is a unique in teger that iden ties the issue. 2. T yp e is an in teger that iden ties the role, group to whic h the rep ort should b e sen t. It can only tak e v alues presen ted in T able 4.3. 3. Mem b er is a unique in teger that iden ties the mem b er of the conference. T able 4.3: V oter T yp es Managed By DSS V oter T yp e Description All Conference Mem b ers All the mem b ers of the conference All activ e mem b ers All the activ e mem b ers. A CS initiated motions No recipien ts, the result is sen t bac k to A CS. Initiator sp ecied The mem b ers sp ecied at the time of initiation. Role All the mem b ers b ound to a sp ecic role. 4.3.8 T emplate This tables k eeps information of all the templates in the conference. Some built in templates are created when the conference is started. Apart from these the users can custom design templates according to their requiremen ts. The user in terface giv es the user the capabilit y to create a new template and select the features he/she needs. This is a global table that is replicated across sites. It has the follo wing elds:

PAGE 53

42 1. T emplateNum is a unique in teger that iden ties the template. 2. T emplateTitle is a string that stores the title of the template. 3. V oting T yp e is a unique in teger that iden ties the v oting metho d. 4. ChangeV ote is an in teger tells if the c hange of v ote option is allo w ed or not. It can tak e v alues 0(NO) and 1(YES) only . 5. Quorum is an in teger that tells if the quorum option is selected. It can tak e v alues 0(NO) and 1(YES) only . 6. ShortCircuit is an in teger tells if the short circuit option is selected. It can tak e v alues 0(NO) and 1 (YES) only . 4.3.9 A CST emplate This table k eeps a list of all the system created templates or templates created with group decision. Only the A CS can use these templates. The templates in this table are dieren t from those in the T emplate table in the w a y that it includes the list of v oters, recipien ts, rep orting st yle and the c hoices. It can also include the features of an existing T emplate from the T emplate table. These could b e motions or issues frequen tly initiated in the conference with xed c hoices, v oters and recipien ts. It stores the follo wing information: 1. P oin ter is a unique in teger that iden ties the templates in A CST emplate table. 2. IssueTitle is a string that describ es the title of the motion. 3. Issue is a string that describ es the issue. 4. T emplateNum b er is a unique in teger that iden ties the template. 5. WinCoun t is a in teger that iden ties the n um b er of v otes required to pass the motion. 6. Range is a string that stores the minim um and maxim um rating/p oin ts allo w ed if the v oting t yp e used it Rating or P oin tDistribution. F or other v oting metho ds it is n ull. 7. Choices is an ob ject that stores the list of c hoices. 8. V oters is an ob ject that stores the list of v oters of the motion.

PAGE 54

43 4.3.10 Arc hiv e This table stores detailed information of all the terminated/withdra wn motions. When a motion terminates all its information is passed on to the Arc hiv e tables b efore deleting its information from the lo cal and global tables. The user in terface giv es the mem b ers the facilit y to searc h the Arc hiv e based on Issue Num b er, Initiator Id, Issue etc. It has the follo wing elds: 1. IssueNum b er is an unique in teger that iden ties the motion. This v alue is returned b y the DSS to the initiator or A CS. 2. Issue is an string that describ es the motion. 3. Initiator Id is an unique in teger that iden ties the DSS mem b er who initiated the motion. 4. StartDate is a date when the motion w as initiated. This is the system date and time at the time the motion w as initiated. 5. EndDate is the date that iden ties the end date sp ecied b y the initiator or the template. If the deadline is relativ e then the absolute calculated and stored in this eld. 6. Result is a string that store the result of the motion. It holds v alues YES or NO for the Ma jorit y and Ma jorit yNeg v oting t yp e and the c hoice selected for other v oting t yp es. 7. InitiatorId is a unique in teger that iden ties the Initiator. 8. WinCoun t is the required coun t for the passage of the motion. 9. FinalCoun t is the coun t v otes for the winning c hoice. 10. V otingT yp e is an in teger that iden ties the v oting t yp e used b y the motion. 11. ShortCircuit is an in teger that iden ties if the short circuit option w as set for the motion. If the motion had the short circuit option it has v alue 1 else 0. 4.3.11 Arc hiv eChoice It is the arc hiv e table that stores the c hoices of the motion. It stores the follo wing information:

PAGE 55

44 1. IssueNum b er is an unique in teger that iden ties the motion. This v alue is returned b y the DSS to the initiator or A CS. 2. Choice is a string that stores the c hoice of the motion. 4.3.12 Arc hiv e Mem b er It is the arc hiv e table that stores the v oters of the motion along with their v otes It stores the follo wing information: 1. IssueNum b er is an unique in teger that iden ties the motion. This v alue is returned b y the DSS to the initiator or A CS. 2. Mem b erId is an uniquer in teger that iden ties the DSS user. 3. Choice is a string that iden ties the c hoice selected b y the user. 4. Role is a in teger that iden ties the role to whic h the user w as b ound while the v ote w as cast. 5. W eigh t is an in teger that stores the rating/rank/p oin ts/w eigh t assigned to the selection. F or the Ma jorit y and Pluralit y v oting metho ds it is n ull. Discussed b elo w are v arious functional mo dules of DSS 4.3.13 Request Manager This mo dule is resp onsible of taking requests from other services of DCS and resp onding to them with the requested information after c hec king their access righ ts and p ermissions. It is also resp onsible for initiating all the motions in the system, collecting and storing its information in the required tables. It c hec ks the access privileges of the initiator at the time of initiation of a motion and if initiator has the p ermissions, it p erforms the necessary actions to start the motion. It also resp onds to the requests from the other Services lik e request for the status of a motion, result of a motion, withdra w al of a motion, Arc hiv e searc h etc. It c hec ks the p ermissions of the user making the request and resp onds accordingly . It main tains the log le that stores the p ending actions or requests, whic h are dep enden t on some motion's result. It stores the action/request along with the motion n um b er of the motion it is w aiting to complete. When the motion

PAGE 56

45 terminates, the request is handled according to the outcome of the motion and remo v ed from the log le. It is also resp onsible for handling remote requests. The Request Manager c hec ks the host site of the motion for whic h the request w as made. It returns the result if motion w as initiated at that site otherwise it con tacts the resp ectiv e site for the information. It is also resp onsible for handling mem b er or initiator drops out of the conference while the motion is in progress. Primitiv es:deleteT emplate() This metho d tak es the T emplate Num b er as argumen t and remo v es the template from the T emplate table. Before deleting it c hec ks if there are an y motions, whic h are curren tly activ e and use this template. It also c hec ks for an y activ e motions using some A CST emplate, whic h uses this template. If b oth the c hec ks return zero results the deletion is done otherwise a message send to the user with appropriate message. insertL o gFile() This metho d is used to store the request whic h are w aiting for the result of another motion. All the w aiting requests are logged along with motion n um b er they are w aiting for to complete. When a motion terminates/withdra wn the log is c hec k ed for an y suc h w aiting request and if an y requests dep enden t on the motion are found, the requests are executed dep ending on the result of the motion. deleteF r omL o g() This metho d remo v es the en tries for the w aiting requests that ha v e b een executed from the log. p erformA ctions() This metho d nds out the w aiting actions to b e p erformed at the termination of a motion and p erforms the request dep ending on the result of the motion. startV ote() This metho d allo ws a user to start a motion. It c hec ks the users access righ ts and v alidit y of the request b efore starting the motion.It creates the appropriate en tries in the GlobalV oteInfo, V oteInfo, Choice, GlobalMem b er and Rep ort tables. It requests the Notication Service to notify all the v oters with the information of the motion. withdr awMotion() -This metho d is resp onsible for deleting the en tries of a motion from all the tables. It c hec ks the access righ ts of the user making the request b efore p erforming the deletes. A motion can only b e withdra wn b y the initiator or b y group decision. getStatus() This metho d returns the status of the motion. DSS supp orts only the status messages presen ted in T able 4.4.

PAGE 57

46 getR esult() This metho d returns the result of the sp ecied motion. If the motion is activ e it returns the string \Activ e" otherwise it gets the result from Arc hiv e and returns the result of the motion. se ar chA r chive() This metho d tak es the searc h criterion and a searc h k ey as parameters and returns the result of the searc h. The searc h criterions supp orted b y DSS are Issue Num b er, Issue Title, End date, Start Date, Initiator Id, V oter Id, V oting T yp e and T emplate Num b er. initiatorDr op out() This metho d gets the user Id of the mem b er who has dropp ed out of the conference. It c hec ks if there are an y activ e motions initiated b y the user. If an y suc h motions are found, the motions are withdra wn and all the v otes and recipien ts of the motion informed ab out it. che ckR eminder This metho d c hec ks for the motions that ha v e deadlines in the next one hour from the curren t time. It tak es in the Mem b erId and returns a V ector of all the p ending motion n um b ers ha ving deadlines in next hour. T able 4.4: Status t yp es Managed By DSS Status T yp e Description Activ e The motion is activ e Withdra wn The motion w as withdra wn T erminated The motion w as terminated. Susp ended The motion w as susp ended eg. timeout,initiator drop out etc. 4.3.14 Deadline Monitor This mo dule is resp onsible of c hec king the deadlines of all the activ e motions and when a deadline is reac hed. It con tin uously c hec ks the deadlines of the motions in the V oteInfo table and when a deadline is reac hed it calls the V ote Manager to mak e decision. All the activ e motions and there deadlines are stored in an arra y and arra y c hec k ed con tin uously for deadlines. When the system starts, it copies all the activ e motions from the V oteInfo table. If a motion is initiated after the service has started, it also inserted in to this arra y along with the table. Similarly it is remo v ed from the arra y on termination/withdra w al. This reduces the n um b er of queries made to the bac k end.It also c hec ks for arc haic motions and remo v es them if timeout for the motion has b een reac hed. Primitiv es:

PAGE 58

47 insertDe ad line() The deadline line monitor stores all the activ e motions in an arra y and the arra y is con tin uously c hec k ed for deadlines. This metho d is resp onsible for inserting the deadlines of motion with motion n um b er in to the arra y whenev er a new motion is started. This metho d is called b y Request Manager when a motion is started and up dates the arra y con taining the activ e motions. r emoveDe ad line() This metho d remo v es the motion en tries for the motions when it terminates or is withdra wn. che ckDe ad line() This metho d is resp onsible for con tin uously c hec king the arra y of activ e motions for deadlines. Whenev er a deadline is reac hed, the V ote Manager is informed and decision made. 4.3.15 V oteManager This mo dule is primarily resp onsible for making decision for the motion initiated in the domain. When the deadline Monitor nds a motion whose deadline is reac hed it calls this mo dule. The V ote Manager then coun ts all the v otes cast for the motion till then and mak es the decision based on the details giv en b y initiator ab out the v oting t yp e and template. After the decision is made, it calls the Rep ort Manager with result details. If short circuit option is selected for the motion, whenev er an ev en t of v oting o ccurs, the V ote Manager coun ts all the v otes cast till then for the motion and c hec ks if a decision can b e reac hed. If decision can b e reac hed, the V ote Manager mak es the decision and con tacts the Rep ort Manager to prepare and send the results. It is also resp onsible for the deletion of en tries regarding the motion from the V oteInfo, GlobalV oteInfo, GlobalMem b er, Choice and corresp onding V ote tables and en tering in to the Arc hiv e tables. If the motion w as initiated b y the A CS, the result of the motion is sen t to A CS on termination. When a v ote is cast, the V ote Manager c hec ks if the motion w as initiated at thatsite. If the site of initiation and v oting are same, it up dates its tables. If the sites do not matc h the site information found from the GlobalV oteInfo table and v ote's information is sen t to the resp ectiv e site. Primitiv es:

PAGE 59

48 makeDe cision() This metho d is resp onsible for making the decision of the motion dep ending on the v oting t yp e and the v otes cast for the motion. up dateAfterDe cision() This metho d is resp onsible for up dating all the tables after the motion terminates and decision made. It mak es the appropriate en tries to the Arc hiv e tables and then remo v es its en tries from the Global and lo cal tables. takeV ote() This metho d is resp onsible for taking the v ote from the user and up dating the appropriate tables with the v ote. If the Short Circuit option is selected, it requests for a coun t of v otes from the \mak eDecision" metho d and c hec ks if a decision can b e made. It gets the issue n um b er, Mem b erId, role of the mem b er, the v ote and v oting t yp e as parameters. Based on the v oting t yp e the resp ectiv e table is up dated. 4.3.16 Rep ort Manager It is resp onsible for getting the list of the recipien ts and corresp onding rep orting st yle from the Remote table and send them the rep ort at the end of motion with the help of NS. The rep orting st yle for eac h recipien t is stored in the Rep ort table. If the recipien t is in terms of role or some groups lik e \All conference mem b ers", the rep ort manager gets the list of users from CCS and A CS who fall in to that category and sends the message. The Manger also c hec ks for rep etitions, i.e. if a user falls in to more than one recipien t group for the same motion. In suc h a case it forms a rep ort including all rep ort t yp es and sends a single rep ort. This mo dule retriev es this information and forms the result ob jects, whic h are then passed on to the Notication Services with other details ab out recipien t and deliv ery t yp e. After the information for all the recipien ts has b een passed on to the NS, the Rep ort Manager deletes the en tries for the motion from the Rep ort table. Primitiv es: pr ep ar eR esult() This metho d c hec ks result t yp e for the recipien t and prepares the result ob ject. It also c hec ks for rep etitions i.e. if a recipien t falls in to more than one group, a single result is prepared com bining the result t yp es of those groups. sendR ep ort() This metho d prepares the result for eac h recipien t and sends the result and recipien t information to the Notication Service.

PAGE 60

49 4.4 Summary This c hapter presen ted the detailed design for Decision Supp ort Services in DCS v.2 based on the requiremen ts presen ted in Chapter 3. It co v ered the arc hitecture of the system, explained the design of the system and functional mo dules of the system. The follo wing c hapter explains the implemen tation of the system.

PAGE 61

CHAPTER 5 IMPLEMENT A TION AND TESTING This rst part of the c hapter discusses ab out the imp ortan t implemen tation details and the testing done on the soft w are mo dule. The design from Chapter 4 has b een implemen ted in Ja v a and tested to meet the requiremen ts sp ecied in Chapter 3. The last part of the c hapter discusses ab out the testing metho ds used to test the system and the scenarios used for that purp ose. Ja v a pro vides us with an easy-to-use set of built-in-library routines and is p ortable across most platforms. Remote Metho d In v o cation (RMI) of Ja v a has b een used to call metho ds on another serv er. Ja v a Swing w as used to build the User In terface as it is standard for all platforms and ensures that the user in terface lo oks the same on all the platforms. The bac k end Database Managemen t System used w as P ostgres. DCS v.2 w as implemen ted on a Lin ux Mac hines \ripley" and \jekyll" running RedHat 7.3. 5.1 Implemen tation Of DSS Decision Supp ort Service is pro vided on a p er conference basis. Eac h conference instan tiated in DCS m ust ha v e its o wn set of tables. The DSS table names are unique and are formed b y the generic name of the table and the conference Id (an in teger that uniquely iden ties a conference), main tained b y Conference Con trol Services. F or example, for conference 1 the table names are GlobalV oteInfo 1, V oteInfo 1, Rep ort 1, etc. The tables are created with the help of createT ables() metho d. DSS sends the SQL command to Database Service(DBS), whic h in turn executes the command on 50

PAGE 62

51 the bac k end P ostgres through JDBC and also propagates the command to other sites [13 ]. The tables used b y DSS ha v e b een discussed in Chapter 4. (Section 4.2) 5.2 In terface Tw o kinds of user in terfaces are pro vided: the Application Programmer's In terface that allo ws programmer's to use DSS primitiv es to dev elop v arious DCS services and the Graphical User In terface that allo ws DCS users to mak e requests to DSS. 5.2.1 Application Programmer's In terface The Application Programmer's In terface is a set of library routines in the form of ob ject link library . The ob ject library allo ws application programmers to use the services pro vided b y the Decision Supp ort Service. F ollo wing are the v arious API calls pro vided b y DSS. in t startV ote( IssueInfo iInfo) v oid withdra wMotion(in t issueNum) v oid tak eV ote(in t IssueNum b er,in t vT yp e, in t c hoiceSelected,in t Mem b erId,in t v oteMo de, Hash table v ote,in t role) sendRep ort(IssueNum) V ector getRep ort (in t IssueNum b er) String getStatus(in t IssueNum b er) v oid Mem b erDrop out(in t Mem b erId) v oid InitiatorDrop out(in t Mem b erId) V ector searc hArc hiv e(in t criterion,String seac hKey) V ector c hec kReminders(in t Mem b erId) These metho ds ha v e b een discussed in detail in Chapter 4 and App endix A.

PAGE 63

52 The classes used b y these functions are giv en b elo w. class IssueInfo f in t IssueNum b er,/* indicate the IssueNum b er */ in t v otingT yp e,/* indicate the v oting t yp e used b y motion */ in t T emplateNum b er,/* indicates the template used */ in t InitiatorId, /* indicates the Id of the initiator */ in t winCoun t,/* indicates the no. of v otes required to pass*/ V ector v oterList,/* indicates the v otes for the motion */ V ector c hoiceList,/* indicates the list of c hoices */ Calendar startDate,/* indicates the time motion w as started */ Calendar endDate,/* indicates the time motion should end */ Hash table rep recList,/* indicates the recipien t and rep ort t yp e */ roat Min rating,/* indicates min rating allo w ed for motions using Rating*/ roat Max rating,/* indicates max rating allo w ed motions using Rating*/ in t P oin ts /*indicates p oin ts allo w ed for motions using P oin tDistr.*/ g class T emplate f in t T emplateNum , /* indicates the T emplate n um b er */ String T emplateTitle, /* indicates the title of T emplate */ in t v otingT yp e, /* indicates the v oting t yp e */ in t shortCircuit, /* indicates if ShortCircuit option is set */ in t ChangeV ote /* indicates if Change of V ote option is set */ g class Rep ort f String decision, /* indicates the decision eg. P ass,F ail */ in t winCoun t, /* indicates the passage coun t */ in t nalCoun t, /* indicates the coun t at the end of motion */ in t winChoice, /* indicates the c hoice selected */ in t a v erage, /* indicates the a v erage of the v otes */ in t mean, /* indicates the mean of the v otes */ Hash table v oteP attern /* indicates the v otes of all v oters */ g All the information regarding the motion is collected in the I ssueInfo ob ject at the time of initiation and up dated in to the tables when the initiator conrms the request. Ob jects of these classes are also used to store the information of a w aiting template or motion creation request in the log le. Similarly the T emplate and R ep ort ob jects, all the information is sa v ed in the mem b er v ariables from the GUI

PAGE 64

53 forms. When the request is conrmed the tables are up dated after p erforming the necessary access and p ermission c hec ks. 5.2.2 User In terface Main Windo w . This is the main windo w of DSS. It has options for v arious motion-related actions. The user can c ho ose to start, withdra w or v ote on a motion. The men u allo ws the user to mak e requests for status, result or v oters of a motion. The user can create, delete or view the templates. The men u has an option that, when selected op ens the Arc hiv e sub windo w. The men u also has windo ws to displa y the reminder messages, discussions and all activ e motions of the conference. Figure 5.1 sho ws the Main Windo w. Figure 5.1: Main Windo w of DSS P ending Motions Windo w . This windo w allo ws the user to view all the motions he is allo w ed to v ote. The user can v ote or c hange an y of his previous v otes using this form. When the user selects a particular motion to v ote or to c hange his v ote, all the c hoices for that motion are displa y ed. The user can then select one of the c hoices to cast his v ote. Withdra w Motions Windo w . This windo w sho ws all the motions initiated b y the user and has an option that allo ws the user to select a motion n um b er and withdra w it. Request Windo w . This windo w allo ws the user to mak e requests for rep ort, result, v oters and status of a motion.

PAGE 65

54 Arc hiv e Windo w . This windo w allo ws the user to searc h the Arc hiv e. The user can select the criterion based on whic h the searc h is made. The results can b e further sorted or selected based on some parameter e.g. IssueNum b er, date, InitiatorId, etc. View Windo w . This windo w has options that allo w the user to view the activ e motions of the conference, reminders and information ab out motions. Activ e Windo w . This is a sub windo w of the View windo w. It sho ws all the activ e motions of the conference at that time. In tiateMotion Windo w . This windo w app ears when the user selects the \Start" option of the main men u. This windo w allo w the mem b er(initiator) to select the v arious parameters of the motion. The user can select the deadline date, v oters, rep ort recipien ts and their resp ectiv e rep ort t yp es for the motion. The user can also en ter the c hoices for the motion and other required parameters lik e passage coun t, max and min rating and p oin ts dep ending on the t yp e of v oting metho d. 5.3 In teraction with Other Services 5.3.1 Conference Con trol Services The CCS ob ject instan tiates the DSS. It is also resp onsible for linking the v arious DCS ob jects. The startup pro cess of eac h DCS service requires t w o phases since eac h service is dep enden t on others. In the rst phase all the service mo dules are instan tiated b y CCS. After this the CCS informs eac h service mo dule to pro ceed to phase t w o, whic h means that other services are up and can b e con tacted. The CCS also tells the services if this is a restart instead of new conference. T able 5.1 discusses the v arious metho ds used b y DSS to in teract with CCS.

PAGE 66

55 T able 5.1: In teraction with CCS Metho d Name Commen ts getSiteId() Returns the home siteId. getSiteInfo(siteId) Imp orted b y DSS to get the site site information (eg IP address) for a particular site. getMem b ers() Imp orted b y DSS to get a list of all the mem b ers of the conference. gotoPhase2(mo de) Exp orted b y DSS. This metho d tells DSS to pro ceed to Phase 2. 5.3.2 Database Services The Database Service exp orts t w o metho ds to access the database and tables. The executeQuery() metho d tak es an SQL query , executes it on the bac k RDBMS and returns the ResultSet ob ject. If no tuple matc hes the query , then the ResultSet is n ull. The executeUp date() metho d up dates the table and propagates the up dates to all sites and k eeps all the tables in dieren t sites in sync ?? bs. 5.3.3 Access Con trol Services The Access Con trol Services and Decision Supp ort Services in teract v ery closely . DSS con tacts A CS whenev er an y request is made to DSS to c hec k if the user is allo w ed to mak e the request. All requests are allo w ed when the A CS returns a p ositiv e answ er and refused if a negativ e answ er is returned. The A CS can also return a motion n um b er, whic h iden ties the motion n um b er dep ending whose decision the request is serv ed. DSS exp orts metho ds lik e startV ote() whic h tak es in the decision p oin ter and a message and returns a motion n um b er [14]. When the v ote is decided, DSS calls the A CS metho d, rep ortResult() to pass the result. DSS also con tacts A CS for information required for the decision pro cess lik e mem b ers b ound to a role, v arious roles allo w ed b y the conference, c hec k if a v ote is still v alid. A CS exp orts metho ds lik e getRoleId() whic h returns the role id of

PAGE 67

56 role, getRoles() whic h returns the roles a user can bind to. DCS can c hec k the p ermissions of a user using the c hec kAccess() metho d of A CS. T able 5.2 presen ts a list of the metho ds exp orted and imp orted b y DSS from A CS. 5.3.4 Notication Services DSS con tact NTS to notify the mem b ers ab out the v arious ev en ts during a decision pro cess. The ev en ts include notifying the mem b ers ab out a motion initiation, reply to a user request, withdra w al or susp ension of a motion and decision rep ort at the end of a motion. DSS imp orts the n tfEv en t() [15] metho d from NTS to send the messages to the mem b ers and recipien ts. 5.4 T esting This section presen ts ev aluation pro cess follo w ed to c hec k to see if the system meets the requiremen ts presen ted in Chapter 3.Both Unit testing and In tegration testing w ere p erformed on the system. 5.4.1 Unit T esting Stubs w ere created w ere for DBS, CCS and A CS. The mo dule w as then tested b y com bining the Graphical User In terface, stubs and the test programs that used dieren t primitiv es. Initiating a motion. As men tioned in the earlier section, the DSS supp orts v arious v oting metho ds, rep orting st yles and v oter and recipien t groups. The system w as tested b y initiating motions with eac h v oting metho d, deadline t yp e, v oter t yp e and rep ort st yle. The tables up dated on motion initiation w ere c hec k ed and they w ere up dated prop erly . Both v alid and in v alid requests w ere made. In v alid requests consisted of in v alid deadline dates and passage coun t. Sp ecial cases lik e mem b er drop out, initiator drop out etc w ere tested b y sending messages from an A CS lik e function and results c hec k ed. The system resp onded correctly and p erformed the correct up dates to the tables.

PAGE 68

57 T able 5.2: In teraction with A CS Metho d Name Commen ts startV ote(p oin ter, deadline) This metho d is exp orted b y DSS whic h tak es in a A CS T emplate p oin ter with deadline and returns the motion n um b er. It starts a motion and p erforms the required up dations to the tables. withdra wMotion(IssueNum b er) This metho d is exp orted b y DSS whic h tak es in a motion n um b er and remo v es the en tries for the motions from the tables. mem b erDrop out(Mem b erId) This metho d is exp orted b y DSS whic h tak es in the userId of the mem b er dropping out. If the mem b er is the initiator of an activ e motion, the motion is susp ended. rep ortResult(IssueNum b er, result) This metho d is imp orted b y DSS to return the result of the motion(initiated b y A CS) on termination. getRoles(Mem b erId) This metho d is imp orted b y DSS whic h tak es in a mem b erId and returns a list of all the roles to whic h the giv en mem b er can bind. getMem b erByRole(role) This metho d is imp orted b y DSS whic h tak es in a roleId and returns a list of mem b ers who can bind to the particular role. getUserRoles(Mem b erId) This metho d is imp orted b y DSS to get a list of all the roles to whic h the giv en mem b er can bind. getRoleId(roleName) This metho d is imp orted b y DSS whic h tak es in a roleName and returns the roleId for the role name. canBindT o(role,Mem b erId) This metho d is imp orted b y DSS. It tak es in a role and mem b erId and returns a Bo olean telling if the mem b er can bind to the giv en role. c hec kAccess(userId, role, Ob jectName, Ob jectId, AccessT yp e) This metho d is imp orted b y DSS. It c hec ks if the giv en user b ound to the giv en role has access to the particular ob ject.

PAGE 69

58 The user in terface c hec ks all the v alues en tered b y the user and if the v alue en tered is in v alid, the user is not allo w ed to mo v e to the next form. The system returned the appropriate error message on an in v alid request. V oting on a motion. After creating a motion, tests w ere run that allo w ed a user to v ote on an issue. The P ending Windo w w as used for this test. The windo w listed only the motions the user w as allo w ed to v ote. Chec ks w ere made to see if the windo w did not list the motions for whic h the user cannot v ote. The \V ote" and \ChangeV ote" options w ere tested. The V ote and GlobalV otes tables w ere up dated when the v ote cast w as v alid. Motions w ere started with short deadlines and the w orking of Deadline Monitor c hec k ed. The deadline Monitor on reac hing a deadline made decision and up dated the required tables. T ests w ere done to c hec k the ShortCircuit option also. The reminder windo ws sho w ed the motions, whic h had deadlines within the next hour. T ermination of motion. All the motions terminated at the prop er time dep ending on the time sp ecied during the initiation. All the tables w ere prop erly up dated after the decision w as reac hed. T ests w ere also carried out to c hec k the withdra w al of motions. T ests included withdra w al from the graphical user in terface and direct calls to API (A CS requests). The en tries for the motion w ere prop erly remo v ed from all tables. P ermission c hec ks w ere made b efore accepting an y request. User requests. These include requests for result, status and v oters . All the requests w ere displa y ed or returned to A CS prop erly . Arc hiv e requests. The Arc hiv e windo w w as used to test the Arc hiv e request. The system could p erform searc h on the Arc hiv e table using the v arious searc h criterion selected. The \Sort" and \Select" options also ga v e the required results. T emplates. The user could create, delete and view templates successfully . A CS requests. T est programs w ere written that made the v arious requests A CS mak es. These include requests for status, result, start motion, withdra w motion,

PAGE 70

59 searc h Arc hiv e etc. The A CS stubs w ere written to return a motion n um b er for a p ermission c hec k. The w aiting request w as sa v ed in the Log le. The action w as successfully completed at the termination/withdra w al of the motion according to the result. The Log le w as tested in this w a y . T ests w ere also p erformed with A CS stub returning p ositiv e and negativ e reply to the p ermission c hec ks. The request w as refused on a negativ e reply and p erformed on a p ositiv e resp onse. 5.5 Summary This c hapter discussed the implemen tation details of Decision Supp ort Service in DCSv.2. Implemen tation details lik e database managemen t in terface for other DCS services and user in terface w ere discussed. The tests p erformed on the system to ev aluate its p erformance w ere discussed. The follo wing c hapter presen ts the conclusions and p oten tial enhancemen ts to the system.

PAGE 71

CHAPTER 6 CONCLUSION AND FUTURE W ORK 6.1 Conclusion The design and implemen tation of Decision Supp ort Services (DSS) for the Univ ersit y of Florida Distributed Conferencing System v2 w as successfully accomplished. The design and implemen tation of the system met the requiremen ts set for this service. The Decision Supp ort Services pro vide a rexible and friendly to ol for initiating and viewing decision pro cesses in the conference to the nal users. The system allo ws the nal user to select the motions that in terest them and view the corresp onding details. DSS allo ws the users to select the v oting parameters, time constrain ts, v oters, rep orting st yles, rep orting time and rep ort recipien ts for decision pro cess. DSS supp orts decision pro cesses for access con trol activities as w ell as direct users. The dieren t v oting metho ds and parameters pro vide lot of rexibilit y to the user. An option for Short-circuit ev aluation exp edites the decision pro cess. T emplates allo w the users to sa v e their requiremen ts and b e reused b y other mem b ers of conference. An Arc hiv e allo ws the user to view terminated and previous motions. This information can also b e used for future reference and designing kno wledge base, graphs etc. The reminders help the user to view the immediate deadlines and a v oid missing of a v ote b y a user. F eatures lik e c hange of v ote, withdra w al of motion, creation and deletion of templates allo w more rexibilit y to the users and decision pro cess. 60

PAGE 72

61 The system allo ws sp ecication of eligible v oters and issue information recipien t groups b y mem b ers and b y role. Dynamic binding of v oters and recipien ts allo ws the v oting or nal result to b e sen t only to the mem b ers b ound to the group at that time. This facilit y is v ery helpful as the system can adapt to an y c hanges in the conference. The time constrain t feature allo ws the users to ha v e con trol o v er when they w an t the system to mak e the decision. DSS pro vides rexible automated rep orting to the users. It also allo ws the users to view the rep ort an y time after termination or while the motion is activ e b y making a request to the system. 6.2 F uture W ork This section discusses the future w ork and p oten tial enhancemen ts to the system. 6.2.1 More Sophisticated V oting Metho ds and Issue Handling The follo wing features can b e added to the system and made more sophisticated.1. Tie Resolution. The curren t system do es not supp ort tie resolution. The system could include v arious tie resolution metho ds men tioned in Section 2.5.2 2. Anon ymous V oting. Curren t system do es not supp ort anon ymous v oting. F uture systems can include this feature. 3. Additional v oting metho ds. Curren tly the system supp orts only Ma jorit y , Ma jorit y with Negativ e v otes, Pluralit y , W eigh ted, Ranking, Rating and P oin t Distribution v oting metho ds. The system could also pro vide other v oting metho ds lik e appro v al v oting etc (Section 2.5.1). 4. Extensibilit y to v oting metho dsThe curren t system do es not supp ort addition of new v oting metho ds without making c hanges to the underlying implementation. The systems should b e able to include new er v oting metho ds and strategies from the user and incorp orate it in the system without c hanging the implemen tation. 5. Extensibilit y of Rep orting The curren t system allo ws some basic t yp es of v oters and recipien ts and union of these t yp es. F uture systems can include more rep ort t yp es and recipien ts. They can also allo w in tersections and

PAGE 73

62 dierence of these t yp es. Negativ e eligibilit y where the initiator can sp ecify the mem b ers, who cannot v ote or receiv e the rep ort, can also b e included. This is will b e useful in cases where there are motions ab out exp elling or promotion of a mem b er. Also the future systems can allo w the mem b ers to design v oter or recipien t groups and rep ort t yp es. 6. Curren t system has v ery simple and rigid rules of mem b er drop out, initiator drop out and c hange of template. More sophisticated metho ds could b e used to handle these cases. (Section 2.5.4) 6.2.2 Iterativ e V oting Metho ds Curren tly the system supp orts only single round decision pro cess. F uture systems can ha v e supp ort for m ultiple and hierarc hical v oting. 6.2.3 More Sophisticated Decision Supp ort 1. Curren tly the system do es not pro vide the user an y information to aid his decision-making. In future, the principles of issue based information systems could b e used to dev elop a kno wledge base, and pro vide decision graphs for the users to exp edite their decision pro cess. 2. Decision Analysis-The curren t system do es not supp ort an y analysis. The future system can ha v e decision analytical metho ds to supp ort decision mak ers in their pro cesses of ev aluating alternativ es and analyzing the result. 6.2.4 Garbage Collection of Arc hiv e Curren t system do es not handle garbage collection of Arc hiv e. F uture systems can ha v e some rule or application to decide the lifetime of motions in Arc hiv e. 6.2.5 W orkro w Mo dels and Decision Mo deling The curren t system do es not supp ort w orkro w mo del supp ort. W orkro w mo dels add the abilit y to execute on a partially dened system where full sp ecication is made at run time. The system will require a pro cess mo deler to mo del the v arious pro cesses of the system. This has b een ac hiev ed in the curren t system b y the use of T emplates. More attributes and features can b e added in the future systems. The future systems can also pro vide decision mo dels whic h analyze the problem and help in deciding the b est p ossible solution.

PAGE 74

APPENDIX A This section discusses a sample scenario used to test the DSS mo dule and the v arious function calls made in the pro cess. Let us assume that the system has 4 mem b ers A, B, C and D, b ound to Chairman, Manager , Assistan t and Emplo y ee roles resp ectiv ely . 1. User A initiates a motion. The system calls the c hec kAccess() metho d of A CS to c hec k if the user has p ermission to initiate motion. The GUI forms tak e all the parameters for the motion. This information is sa v ed in IssueInfo ob ject. The system then mak es a call to up dateInitiate() metho d. up dateInitiate(IssueInfo iInfo) f /*Insert the v oting parameters in to the required tables. */ g 2. User B initiates a motion. The system initiates the motion with all the parameters and returns Motion Num b er 2 to the initiator(User B). 3. User A c hec ks his p ending motions in the P ending windo w and v otes for Motion 1. The system no w mak es a call to up dateV oteDatabase() metho d. v oid Up dateV oteDatabase(in t IssueNum, in t vT yp e, in t c hoiceSelected, in t Mem b erId, Hash table v otes, in t role) f /* Up date the resp ectiv e v oting database. */ /* If the motion has the Short circuit option set, c hec k if the pass coun t has b een reac hed. */ g If motion uses Short-Circuit and the pass coun t has b een reac hed the system mak es a call to the up dateAfterDecision() metho d. 4. User B w an ts to withdra w Motion 2. User B is the initiator of the motion and hence has p ermission to withdra w. The system mak es a call to withdra wUpdate() metho d. withdra wUp date(in t IssueNum, String commen t) f 63

PAGE 75

64 /* Inserts the motion information in to Arc hiv e.*/ /* Delete the en tries for the motion from all the activ e databases.*/ g 5. User C w an ts to create T emplate. The system calls the accessChec k() metho d of A CS. The A CS returns a motion n um b er 2 i.e. User C is allo w ed to create template if Motion 2 is passed. The system calls the metho d insertLogFile() to log the request till decision is made. InsertLogFile(in t issueNum,in t actionNum,in t actionV al) f /* Sa v e the request in log le. */ g 6. Deadline for Motion 1 is reac hed. The Deadline Monitor mak es a call to the DeadlineReac hed() metho d. v oid DeadlineReac hed(in t IssueNum, f Rep ort result mak eDecision(in t IssueNum, in t vT yp e); up dateAfterDecision(IssueNum, vT yp e, winChoice, nalCoun t); sendRep ort(IssueNum, result); gup dateAfterDecision(in t IssueNum, in t vT yp e, in t winChoice, in t nalCoun t) f /* Chec k the log for an y requests w aiting for the result of this motion. */ If(winChoice!=0) f /* Motion passed */ V ector actions=getActionsF romLog(IssueNum); p erformActions(actions); /* p erforms all the w aiting requests */ f /* Up date the Arc hiv e tables */ /* Remo v e en tries from activ e tables */ gsendRep ort(in t IssueNum, Rep ort result) f /* prepare the Rep ort ob ject and send it to NS */ g 7. User D requests for status of Motion 2. The access p ermissions are c hec k ed. If the user has p ermission, the system mak es a call to the getStatus() metho d. String getStatus(in t IssueNum) f /* If motion is activ e return \Activ e". */

PAGE 76

65 /* Else Chec k the Arc hiv e table and return the v alue in the Result eld of Arc hiv e table. */ g

PAGE 77

REFERENCES [1] J. Conklin , B. Begeman and M. Gibis. A h yp ertext to ol for exploratory p olicy . In Pro ceedings of the Conference on Computer-Supp orted Co op erativ e W ork, P ortland, Oregon, pp 140-152, 1988 [2] G. DeSanctis and R.B. Gallup e. A foundation for the study of group decision supp ort systems. Managemen t Science, 33:589-609, 1987. [3] R. E. Newman-W olfe and H. K. P elim uhandiram. Mace: A ne-grained concurren t editor. In Conference on Organizational Computing Systems, A tlan ta, Georgia, pp. 240-254, 1991. [4] A. Narla . Decision Supp ort Services in Distributed Conferencing System, Master's thesis, Univ ersit y of Florida,1996 [5] A. R. Dennis, J. F. George, L. M. Jessup, J. F. Nunamak er, and D. R. V ogel. Information tec hnology to supp ort electronic meetings. Information tec hnology to supp ort electronic meetings 12:591-609, 1988 [6] T. Brinc. Group w are. h ttp://www.usabilit yrst.com/group w are/in tro.txl (Accessed 10/20/2001) [7] K. L. Kraemer and J. L. King. Computer-based systems for co op erativ e w ork and group decision making. A CM Computing Surv eys, Irvine, California pp. 115-140, 1988 [8] K. W atab e, S. Sak ata, K. Maeno, H. F ukuok a, and T. Ohmori. Distributed m ulipart y desktop conferencing system: Mermaid. In Pro ceedings of the Conference on Computer-Supp orted Co op erativ e W ork, Los Angeles, California, pp. 27-38, 1990 [9] J. Lee. Sib yl: A to ol for managing group design rationale. In Pro ceedings of the Conference on Computer-Supp orted Co op erativ e W ork, Los Angeles, California, pp. 79-91, 1990 [10] R. E. Newman-W olfe, C. L. Ramirez, H. K. P elim uhandiram, M. Mon tes, M. W ebb, and D. L. Wilson. A brief o v erview of dcs distributed conferenceing system, Departmen t of Computer and Information Science and Engineering, Univ ersit y of Florida 1991. 66

PAGE 78

67 [11] D. Lo v elo c k. V oting h ttp://arc hiv es.math.utk.edu/soft w are/msdos/dis cre te.math/v oting/.h tml (Accessed 11/23/2001) [12] L. S. Maisel. V oting metho ds h ttp://b cn.b oulder.co.us/go v ernmen t/appro v alv ote/altv ote.h tml (Accessed 11/23/2001) [13] A. V. Date. Implemen tation of Distributed Database and Reliable Multicast for Distributed Conferencing System v ersion 2, Master's thesis, Univ ersit y of Florida, 2001. [14] V. Manian. Access Con trol Mo del in Distributed Conferencing System v ersion 2, Master's thesis, Univ ersit y of Florida, 2002. [15] S. P atanjali. Notication Services in Distributed Conferencing System v ersion 2, Master's thesis, Univ ersit y of Florida, 2000.

PAGE 79

BIOGRAPHICAL SKETCH Aparna Kak arparti w as b orn in Andhra Pradesh, India. She receiv ed a Bac helor in T ec hnology degree in computer science from Ja w aharlal Nehru T ec hnological Univ ersit y in 2000. She then came to Univ ersit y of Florida to pursue her master's in computer science. She will graduate in Decem b er 2002. 68