Proceedings of the 10th International Conference on Computer Supported Cooperative Work in Design

Building Tools for Emergent Design with COPPEER

Mutaleci Miranda' 2. Geraldo Xexeo2,3. Jano Moreira de Souza2'3'Se,cao de Engenharia de Sistemas, Instituto Militar de Engenharia, Brazil

2Programa de Engenharia de Sistemas e Computa,cao (COPPE),Universidade Federal do Rio de Janeiro, Brazil3Departamento de Ciencia da Computa,cao (IM),Universidade Federal do Rio de Janeiro, Brazil

mmiranda@de9. ime. eb. br, xexeo@cos. ufrj. br; jano@cos. ufrj. br

Abstract

In this work, we first present a model of emergentdesign which allows a community of designers tocollectively translate a set of requirement specificationsinto a completed design. Then, we describe theCOPPEER framework, an environment for developingand running collaborative peer-to-peer applicationswhich directly supports the main requirements elicited inour proposal.

Keywords: Emergent design, multi-agent systems, toolsfor CSCW in design.

1. Introduction

In this work, we propose and implement an emergentsystem approach to allow a community to performcollective design.

Emergent behavior appears when complex globalbehavior results, probably in an unexpected way, from theinteraction of a great number of agents with differentindividual behaviors among themselves and with theenvironment.

In our model, emergent design is the translation of aninterrelated set of system requirements into a set ofinterrelated system element models performed by a greatnumber of agents, subject to some conditions, such as nocentral coordination. We believe that this model, althoughhighly conceptual, describes in a realistic way a largenumber of collaborative design situations.

Technically, emergence is a good way to builddecentralized, fault-tolerant and scalable systems withacceptable overhead in network communication. To buildemergent systems, a peer-to-peer approach is veryadequate.We also introduce the COPPEER 2.0 framework, an

environment for developing and running collaborativepeer-to-peer applications which directly supports the mainrequirements elicited in our proposal.

The remainder of this work is organized as follows. Inthe next section, we present relevant emergence principles.In Section 3, we describe our emergent design model. InSection 4, we propose an illustrative example of anemergent design tool. In Sections 5 and 6, we present theCOPPEER framework. In Section 7, we discuss someguidelines to use COPPEER in the implementation ofemergent design tools. In Section 8, we point out somerelated work and finally, in Section 9, we conclude anddiscuss some open issues.

2. Emergence

Emergent systems, also referred to as ComplexAdaptive Systems (CAS), are composed of a greatnumber of agents which can interact with one another andwith an environment in such a way that system functionsmay be accomplished despite some degree of individualagent failures and unexpected environmental changes. Anumber of examples of natural CAS can be seen in [6].

The term emergent is an abbreviation for emergentbehavior. This indicates that there are non-trivialrelationships among individual element behaviors and theglobal system behavior.

Emergent systems are stigmergic and heterarchical. Asystem is said to be stigmergic if communication amongits elements is mediated by an environment.Heterarchical systems are characterized by the fact thatany element can influence any other element behavioraccording to circumstantial system needs, in contrast withhierarchical systems, in which the set of elements ispartitioned in ordered levels and the behavior of eachelement is controlled by a fixed element from a higherlevel.A peer-to-peer system can be modeled as a CAS in a

very straight way: the network of peers represents theenvironment; programs and people that modify the stateof the environment represent system agents. However,system designers must be careful with the properties ofthe emergent approach.

1-4244-0165-8/06/$20.00 ©2006 IEEE.

Proceedings of the 10th International Conference on Computer Supported Cooperative Work in Design

First, stigmergic communication demands what wewill refer to as data bounding principle: there must existequilibrium among the amount of data generated byagents, the storing and propagation capacity of theenvironment and the processing capacity of receivingagents.

Similarly, the heterarchy principle raises the need for aproper system topology. To potentially influence anyother agent in the system, an agent should be able totraverse paths or propagate data to any peer in thenetwork. An approach to efficiently achieve that isdiscussed in Section 6.

3. Emergent design model

We define emergent design as the translation of aninterrelated set of system requirements into a set ofinterrelated system element models, performed by a greatnumber of agents with no direct communication, centralcoordination or global knowledge.

Let R be the set of all possible requirements expressedin a given requirement language andM a R, the set of allpossible model elements expressed in a given modelinglanguage. A design is represented by a tuple D = (S, I)where:

S a R is a set of specifications;I is a set of directed links of the form (xE S-M, yE S) or (xE SnM, y E SnM), representing thatthe specification x cites the specification y.

From the definition ofR andM one can notice that themodeling language is a specialization of the requirementlanguage. Hence, the first statement declares that weconsider that combinations of requirements and modelelements can represent a design, ranging from the initialrequirement specifications to the completed designcomposed only of model element specifications. Thesecond statement, in turn, claims that a requirementspecification can cite an element model specification, butan element model specification can only cite anotherelement model.

Agents must perform a sequence of operations oninitial requirement specifications to derive a completeddesign. These operations must generate only syntacticallyand semantically correct designs. Syntactic correctness isassured by not creating links from model elements torequirements. Semantic correctness, in turn, is assured bythe following rule: if a link from a specification x to aspecification y is replaced by a link from x to aspecification z, then z must be an extension of y, that is,the original meaning of x must be preserved in theoperation. A detailed definition of allowed designoperations in our model is provided in the followingparagraphs.

Let A be a set of agents and T = A*the set of allsubsets of A. The allocation of a design is a functiont:S->T which maps each specification of a design into a

team of responsible agents. If a team of agents isresponsible for a specification, it is allowed to performoperations for partitioning, merging, relocating andtranslating the corresponding design and its allocation.

The partitioning operation replaces a specification s bya set P of interrelated specifications from the same type(requirement or model element) of s, and all linksinvolving s by links involving some P member in thesame direction. The team becomes responsible for the Pmembers;

The merging operation replaces a set P of interrelatedspecifications from the same type by a specification s andall links involving some P member by links involving s inthe same direction. The team becomes responsible for s;

The relocation operation passes the responsibility for aspecification to another team of agents, changing theallocation of the design;

The translation operation replaces a requirementspecification ri by a model element specification ml andall links involving ri by links involving ml. Furthermore,if a requirement specification r2 is cited by ri, theoperation will create an element model i(r2) to be citedby ml in place of r2, and a citation from r2 to i(r2),which claims that its translation has to be an extension ofi(r2). The team becomes responsible for both ml andi(r2). If r2 is translated by another team into a modelelement m2 in parallel to the creation of i(r2), then thisteam must create an additional element model a(m2) toextend i(r2) and cite m2 in place of ml .

As we have defined all operations in terms of teams,agents in a team need to communicate among themselvesto perform these operations collectively or to elect anagent to work on behalf of the whole team. Furthermore,an operation on a specification may imply replacing orinclusion of citations in other specifications controlled byother teams. Hence, communicating among agents fromdifferent teams may be needed too.

In emergent systems, both aforementioned situationsinvolve stigmergy: information on operations has to beput in a supporting environment to be retrieved by anyinterested agent. In Section 7, we will explain how thatcan be accomplished by COPPEER.

4. Illustrative example: UML tool foremergent design

In this section, we present a simplistic example toclarify the model presented in Section 3. The requirementlanguage is natural language and the modeling languageis some textual notation equivalent to the UML classmodel. Hence, we can consider the modeling language asa specialization of the requirement language.

Agents are human designers who use workstationsconnected to a common computer network. Each onejoins one or more teams which, in turn, are responsiblefor one or more specifications.

Proceedings of the 10th International Conference on Computer Supported Cooperative Work in Design

The tool offers as support for team operations anEmergent Electronic Blackboard System (EEBS) and avoting system. The EEBS maintains the workstation ofeach agent in a team connected to n neighbors on average,where n should be a small number to respect the databounding principle. Every agent receives a specificationand is asked to register in the system a proposal operation.After that, each agent reads the proposal of her neighbors,analyzes them and updates her own proposal in thesystem. This updating phase is repeated several times.

The expected result is the emergence of a few goodproposals spread over the system in slightly differentversions. Then, the voting system allows agents to browseand to vote for proposals, and applies the winningproposal to the specification. Finally, the tool notifiesteams responsible for related specifications in order toallow modifications in citations.A simplistic example of requirement specification in

natural language is shown in Table 1 and a possibletransformation in a completed design is depicted in Figure1. The specification corresponds to a description of alibrary loan log and is initially allocated to a team namedteamA.

After teamA agents agree on performing a partitioningand a relocation, the resulting design is composed of a logdescription, a person description and a book descriptionallocated respectively to teamA, a second team, teamBand a third team, teamC, as shown in Table 2, whichpresents citations underlined, as do the subsequent tables.

Table 1. Initial requirement specification

Name Team

Library loanlog description

Content

TeamA "... the log registers allbooks each person hasalready loaned ... a person isdescribed by name,address,... a book isdescribed by title,author, ..."1

Name Team

Logdescription

Persondescription

Bookdescription

Content

TeamA "... the log registers all bookseach person has alreadyloaned."

TeamB "... a person is described byname, address,..."

TeamC "... a book is described by title,author, ..."1

In the following step, teamA agents agree onperforming a translation, replacing log description bythree element models: log class, client interface and iteminterface. TeamB and TeamC are notified to add citationsin person description and book description respectively.The result is shown in Table 3.

Finally, TeamB e TeamC agents agree on performingtranslations generating the element models person classand book class respectively, shown in Table 4.

Table 3. Log description translation result

Name Team Content

Log class TeamA Class Log{ Item logltem;Client logClient; ... }

Client TeamA Interface Client{ ... }Interface

Item TeamA Interface Item { ... }Interface

Person TeamB ... a person is described bydescription name, address, ... must

extend Client"

Book TeamC "... a book is described bydescription title, author, ... must extend

Item"

Table 4. Person and book translation result

TeamB TeamA TeamC

[ Library Loan[log description I

I | p~~~~~~artiotion ing,pre )cation

Person Log I-fBookdescription description :description

I I~~~~translationnotification t notification,

Person ij Client Lo tm i Bookdescription I| interface class interface description

;translationi itranslation

|class I interface class interface class

Figure 1. Example operations

Table 2. Partitioning and relocation result

Name Team

Personclass

Bookclass

Content

TeamB Class Person implementsClient{ String name; Stringaddress ... }

TeamC Class Book implementsItem{ String title; Stringauthor ... }

5. The COPPEER 2.0 framework

COPPEER is a research project in progress at theDatabase Laboratory of the Federal University of Rio deJaneiro Graduate School and Research in Engineering(COPPE/UFRJ). The first version of COPPEER was

Proceedings of the 10th International Conference on Computer Supported Cooperative Work in Design

conceived as a peer-to-peer framework to support gridcomputing architectures such as the Open Grid ServicesArchitecture (OGSA)[ 1].

Currently, COPPEER 2.0 project goal is theimplementation of a framework for developing andrunning collaborative peer-to-peer applications under acomplex adaptive system paradigm. The globalarchitecture of COPPEER 2.0 is composed of fourlayers:

* agency layer: performs generic P2Pcomputations to attend needs of other layers;

* market layer: encompasses application locationand session management;

* integration layer: offers high-level distributedcomputing paradigms to components ofapplications;

* application layer: handles collaboration-relatedissues.

We have developed an agency layer implementation asa runtime environment for complex adaptive systemsnamed CoppeerCAS. The main entity in CoppeerCAS isthe agency. When CoppeerCAS is started in a peer, anagency is created to manage environments, cells andagents on behalf of applications.An environment is a set of interconnected cells. An

agency can participate in many environmentssimultaneously, but can manage only one cell perenvironment. So, a cell is unambiguously identified by itsagency and its environment.A cell is a shared space based on the JavaSpace

specification[3], which offers its clients an interfacecontaining operations to write and read entries, subscribefor notification about the writing of entries containingspecified data and establish or terminate connections toother known cells.A client of a cell can be an agent or any application

object. A leasing mechanism is employed to control forhow much time a cell will be able to attend a clientrequisition. When a client wants to store an entry, itspecifies an intended lease duration. Then, cells useapplication-specific LeaseStrategy objects to determineeffective lease durations.

An entry is a data object which can, when stored in acell, continuously propagate data to neighbor cells andchange its own internal state. Application developers maycreate entries with desired rules of propagation byimplementing a set of propagation cycle methods.

An agent is a piece of software associated with anenvironment which accesses cells and moves acrossagencies to perform distributed computations. Agents cancreate new agents, move from the current agency to anagency containing a neighbor cell in its environment andaccess the interfaces of the current cell and neighbor cells.

In order to determine the behavior of agents,application developers should create a behavior object,implement methods which will be invoked when relevant

events such as creating, moving or cell notification occur,and pass the object to the agency during agent creation.An agency is composed of an agent manager, a cell

pool and a connection manager. The agent manager is thecomponent which effectively handles execution andmobility of agents. The cell pool manages creation ofcells and controls application access to them. Theconnection manager handles links between cells and otherobjects needed to exchange data between agencies.

The current version of CoppeerCAS is implemented inJava and therefore can be used in a variety of hardwareplatforms. Both agent manager and connection managerare based on the Aglets platform[4]. Cell contents arestored in hash tables allowing good performance for thesystem. CoppeerCAS is structured according to a SpringMicrokernel [7] architecture which allows addition ofsystem modules at run time.

6. Topology maintenance in COPPEER

The heterarchy principle demands that there must bean easy pathway between any two system elements of anemergent system. In order to satisfy it withoutoverloading cells with a great number of neighbors,COPPEER employs small-world topologies.A small-world network shows small average minimal

path length and high clustering coefficient simultaneously.These properties can be achieved even in low degreenetworks, that is, networks in which each network nodehas a low number of neighbors.

The clustering coefficient of a node is the ratiobetween the number of edges among its neighbors and thenumber which would exist in a fully connectedneighborhood. The clustering coefficient of a network isthe average coefficient over all nodes. A high clusteringcoefficient makes small-world networks very goodsubstitutes for complete networks since this, as well asshort minimal paths, facilitates information dissemination.We developed an agent-based method to maintain a

small-world topology in a large and dynamic network, byadapting the Watts-Strogatz method[8]. In our method,cells are distributed at random in an imaginary ring withunitary perimeter and two kinds of connections areallowed: close neighbor connections between cellslocated at close positions in the ring, and shortcutconnections, between cells located at far positions. Themain parameters of the method are:

n: maximum number of cells in the environment;&d maximum distance to a close neighbor;h: maximum number of agent hops, andr: ratio between the number of shortcutconnections and the number of close neighborconnections.

Each entering agency generates a random number 1 E[0,1] which represents its position on the ring. Anentering agency should know at least one agency already

Proceedings of the 10th International Conference on Computer Supported Cooperative Work in Design

in the environment. We will refer to this known agency asentry agency. The entering agency cell connects to theentry agency cell and periodically sends random walkeragents to collect addresses of available close neighbors,that is, cells whose distance to the entering agency cellover the imaginary ring is less than or equal to d. After, atmost, h hops, agents return to the entering agency andestablish connections to discovered cells.

Besides that, agencies send a second kind of randomwalker to collect addresses of far cells and to connect tothem maintaining the ratio between the number ofshortcut and close neighbor connections around r. Eachone of these agents performs until h hops, returns to itssender, selects a discovered far peer at random, andestablishes a shortcut connection. Some simulation resultsfrom this algorithm can be found in [9].

7. Implementing emergent design tools withCOPPEER

In the following paragraphs, we will explain in generalterms how COPPEER features can be used to implementthe emergent design model described in Section 3.

Each team can have its own COPPEER environment tohandle its specifications. A specification can be stored asan entry in one cell of the environment and replicated inother cells through the propagation mechanism todecrease search time and increase system availability. Inorder to allow fast information dissemination in a team, atopology manager application can be employed tomaintain a small-world topology in each environment.

The topology manager is the direct implementation ofthe small-network maintenance method described inSection 6. Each cell must store an entry containing itsposition on the imaginary ring. Visiting walker agentsread the entry to compare to their sender positions anddecide if they are in a close neighbor or not.

In the presence of proper topologies for teamenvironments, mechanisms for team coordination can beimplemented with basic COPPEER features. The EEBSdescribed in Section 4, for example, can be composed ofwriting and reading interfaces to human agents. Thewriting interface stores each agent proposal as an entry inthe local cell. The reading interface just reads allneighborhood proposals and presents them to the humanagent when required. The voting system, in turn, can relyon the propagation mechanism to elect a proposal and anagent to perform the corresponding operation in thespecification.

As an operation can imply modifications inspecifications located in different environments, a globalenvironment must encompass agents from all teams.Whenever an agent performs an operation, she must storean entry describing the operation in her cell in the globalenvironment. Then, the global environment will

propagate that entry and all agents who had subscribed toevents in that specification will be notified.

In order to allow for correctness of designs afteroperations, agents must subscribe to the globalenvironment for events in specifications which:

are replicated on a local cell;cite a specification on a local cell;

* are cited by a specification on a local cell.

8. Related work

Approaches for coordinating a great number of peoplein very complex projects are a subject in the collaborativedesign area. In [10] we can find a modeling similar to ouremergent design modeling. However, that work focuseson negotiating to conciliate choices of agents responsiblefor interdependent subsystems. In its proposal,negotiations must be mediated by experienced agents andcan take several iterations. In our proposal, negotiating isrestricted to team members working in the samesubsystem through a stigmergic brainstorming mechanism.Conciliation between interdependent subsystems isachieved through cooperation, that is, agents make effortsto build proper interfaces to subsystems designed by otheragents. Information needed for cooperation is alsoexchanged through stigmergy.

Anthill [5] is a framework for developing P2Papplications similar to CoppeerCAS. However, Anthilldoes not implement agent-independent data propagation.The TOTA middleware [2] offers stigmergiccoordination for agents through a simple API designedfrom scratch. As TOTA project is mainly devoted tomobile ad-hoc networks, it doesn't explore small-worldtopologies.

9. Final Remarks

We have described a model for emergent design, andpresented an infrastructure to build peer-to-peercollaborative applications which is well-suited forimplementing the model.

In the current implementation, a COPPEERenvironment is a set of interconnected shared memories.If an agent located in a given cell needs to be notified ofan event that occurred in an unknown cell, the developermust implement an ad-hoc procedure exploring thepropagation mechanism. Future implementation of theintegration layer will provide general-purposeabstractions which will allow agents to treat environmentsas a unified shared memory. Furthermore, theimplementation of the market layer will simplifymanagement of agent teams.

Some other steps needed in our research to increasethe applicability of the presented approach are theimplementation of security and privacy capabilities inCoppeerCAS and refinements in the emergent design

Proceedings of the 10th International Conference on Computer Supported Cooperative Work in Design

model to comprehend physical requirements such as timeconstraints.

References[1] Souza, J. et al., COE: A collaborative ontology editor basedon a peer-to-peer framework, Advanced EngineeringInformatics, 19(2):113-121, 2005.[2] Mamei, M, Zambonelli, F., Programming stigmergiccoordination with the TOTA middleware, Proceedings ofthe AAMAS'05, 2005, pp.415-422.[3] JavaSpaces. http://www.sun.com/software/jini/specsjinil . lhtml/js-spec.html[4] Aglets (2005). Aglets. http://www.trl.ibm.com/aglets/[5] Babaoglu, 0. et al., Anthill: A Framework for theDevelopment of Agent-Based Peer-to-Peer Systems.Proceedings ofthe 22th ICDCS, 2002.[6] Parunak, H., Go to the Ant: Engineering Principles fromNatural Agent Systems, Annals ofOperations Research, 1997.[7] Spring Framework. http://www.springframework.org[8] Watts, D., Strogatz, S., Collective dynamics of small worldnetworks, Nature, 393:440-442, 1998.[9] Miranda, M., Xexeo, G., A complex adaptive systemapproach for agent-based peer-to-peer collaborativeapplications, Proceedings ofthe WTDBD'05, 2005.[10]Klein, M. et al., Negotiating algorithms for collaborativedesign settings, CERA '03, 2003.