Model-driven communications and collaborative software development

(1)

Model-driven communications

and collaborative software development

Antonio Natali

Alma Mater Studiorum – Universit`a di Bologna

Abstract Custom languages inherently associated –via meta-modeling– with the concrete organization of software systems, can promote not only better products, but can also allow people to efficiently describe and un-derstand their collaboration, by identifying relevant relationships among tasks, developers and artifacts within a particular work context. This pa-per makes reference toContact [1], a language usable as a meta-model for high-level communications within distributed systems, to show how it can promote structured forms of collaborations between workers with different skills and scope (e.g. customers, application designers and sys-tem designers), by providing at the same time other important benefits typical of theModel Driven Software Development (MDSD) approach [2]:

i)the formal definition of a conceptual space useful in all the phases of software development;ii)the possibility to build a customsoftware fac-tory that explicitly represents and spread the know-how of a company; iii) the automated construction of infrastructures tailored to application needs;iv) the usage of models as a new form of source code that can allow application designers to write platform-independent code.

Keywords: Cooperative work, Meta-modeling, Communication, Soft-ware Factory, Eclipse, XText.

1 Introduction

Software applications become increasingly heterogeneous and distributed and communication takes an increasingly central role in modern serviceoriented -software systems. Communication is commonly defined as ”the interchange of thoughts, opinions, or information by speech, writing, or signs”. The problem is that current programming languages do not provide adequate expressive power and for many software developers, communication is only the emerging result of activities performed by using some software component providing communica-tionmechanisms. As a consequence, the task of designing and building software components more related to a communication infrastructure rather than to the business logic is often repeated several times, each time in a different way. Worst, the analyst and the designer have no reference language to build alogic archi-tecture of the system, with the intent to talk with customers at their abstraction level and to summarize information useful to evaluate the risks and to define well-founded plans for software development.

(2)

Thanks to Eclipse-based technologies, appropriate application-oriented concep-tual spaces can be defined as meta-models introduced as custom domain specific languages (DSL). According to theMDSD[2] approach, model-to-model (M2M) and model-to-code (M2C) transformers can provide a custom Software Factory able to reduce the gap between models and code and to produce in automatic way the intrinsic systematic of an infrastructure as part of an user-defined design.

MDSDpromotes also the possibility to organize in a structured and unambi-guous way the cooperation among the workers of a team. In fact, people working on the application logic (called from now on application designers) can define in a formal way new abstractions peculiar to the application domain. On the other hand, the team members more involved into the technical details of a in-frastructure (called from now on system designers) can produce not only new operational platforms tailored to application needs, but also newconceptsusable as they wereprimitive. New primitive concepts, defined by keeping into account specific application problems, are essential to face in an effective way the analy-sis and the design phase of modern software systems1. Each software company could define, implement and use its own set of primitive concepts, by providing a customIDE, based, in its turn, on custom meta-models usable as conventional (domain specific) languages. The activities of a team can be planned around this customIDEthat becomes the main artifact able to explicitly represent and trans-mit the knowledge and the know-how of the company both in the application domain and in the (relationship with the) supporting technologies.

The aim of this work is to discuss these perspectives with reference toContact

[1], a language (a meta-model) that has been defined by exploiting Eclipse, Eclipse EMF[3] and theXtext2.0[4] framework. The aim of Contact is to help application designers in:i)building models of high-level communication patterns that can be used as a new form of source code; ii) defining in a systematic way –related to the definition of the operational semantics of the language– the communication infrastructure; and iii) creating the IDE (Contact-ide in the following) that makes the language usable.

The work is structured as follows. The Section 2 introduces the Contact

meta model and gives an informal overview of its conceptual space, by intro-ducing the primitives that the language provides. The Section 3 discusses the impact ofContact on the production process with reference to an example. The collaboration between application and system designers is discussed in Section 4, with reference to a set of technical and logical problems that can arise when the system must be transformed from a prototype to a true distributed system. This section gives also some detail on how the model-driven approach helps in struc-turing an application as a layered system in which each layer is associated to a proper meta-model. Finally Section 5 is devoted to the conclusions.

1 _{Imagine what could be a modern software production process without concepts like}

(3)

2 The

Contact

meta-model

It is quite common to say that, in order to communicate, two software enti-ties should ”exchange messages”. Since sentences such as ”send a message” or ”receive a message” are not well defined, a more appropriate vocabulary for message-based interaction is needed. The main goal of theContact language is to provide aconceptual space (and an associated vocabulary) to express a basic set of high-level forms of communication. TheContactconceptual space is based on aMessage ontology defined inXText2 (only a subset of the message types is shown):

Message:

OutOnlyMessage|OutInMessage; OutOnlyMessage: Signal|Dispatch ; OutInMessage: Request|Invitation;

OutOnlyMessage: information that a subject sends (to some other subject) without any expectation to receive a reply re-lated to that message.

OutInMessage: information that a subject sends (to some other subject) with the expectation to receive some reply (e.g. an ack, an answer, etc.) related to that message.

EachMessagetype is associated with a pair of high level operations (one to send information and one to receive information) like those written in bold in Table 1, that reports an informal description of the Message semantics3_{. The}

exact semantics of each term of the vocabulary is (operationally) defined by the system designer (see Subsection 4.1), which concurs also to the definition of the language with appropriate feedbacks.

MsgType Informal meaning

Signal a (OutOnlyMessage) message that a subject canemit on thesharedSpace; a signal can besensedbyN>=0time uncoupled subjects.Example: a click of the mouse (a signal that can be perceived by a window).

Dispatch a (OutOnlyMessage) message that a subject canforwardto one specific receiver-subject, with the expectation that it willserve it.Example: a message sent by a general to his colonels on the battlefield.

Invitationa (OutInMessage) message that a subject canasktoND>=1receivers, with the expectation toacquireNR>=0acknowledgments (ack); a receiver willacceptan invitation and willreply with anackto the sender.Example: a message sent by a government of a country to all its ambassadors in order to do something.

Request a (OutInMessage) message that a subject candemand toND>=1receivers, with the ex-pectation toacquireNR>=0responses; a receiver willgrant a request and willanswer to the sender with aresponse.Example: a message sent to know something.

Table 1.Message informal semantics

The main idea underlying theContact conceptual space is that a distributed system is composed of a set of entities, calledSubjects4_{, each associated with a}

unique name; the subjects can exchange information via the sharedSpace abs-traction. ThesharedSpacedefines basic operations to write (out), read (rd,rdw) or consume (in) information defined by an interface namedILindaLike.

2 _{Thus, each}_Contact _{specification is also a model, instance of a meta-model.} 3

This vocabulary is open-ended, since it is proposed to capturecommunication pat-terns that frequently occur in the application domain.

4

(4)

ILindaLike public interface ILindaLike {

public IMessage in(String query) throws Exception;

public IMessage rd(int LastMsgNum, String queryMsg) throws Exception; public IMessage rdw(int LastMsgNum, String queryMsg) throws Exception; public void out( String msg ) throws Exception;

public Vector<IMessage> inMany(Vector<String> tokens) throws Exception;

public IMessage selectOneFromMany(int msgNum,Vector<IMessage> queries) throws Exception; public void terminate() throws Exception;

}

ILindaLikeoperations are used as the reference machine to define the ope-rational semantics of Contact (see Subsection 4.1). High-level communication patterns are associated to theMessage types and can be expressed by means of a set ofHighLevelOperation defined inXTextas follows:

AnOutOperationis an instance ofOpOut. AnInOperationis an instance ofOpIn.

OpOut: used to send information. OpIn: used to acquire information.

The definition of the language includes a concrete syntax (theContact language itself) and an abstract syntax expressed by the intermediate language medcl. High-level operations can be viewed as a set of primitives whose concrete no-tation is provided by Contact and whose semantics is defined by a run time support built over on a lower-level support that implements the ILindaLike interface according to the meaning given to themedclmeta-model (see Subsec-tion 4.1).

TheILindaLikeinterface can be ignored by the application designer, since the behavior of each Subject is conceived, at application level, as a finite state machine (FSM) whose state transitions are associated to application-specific, ge-nerated communication methods, whose structure can be sketched as follows:

Output operation scheme

<AnswerType> hl_<SenderName>_<OperationName>_<messageId>_<ReceiverName>(String M){

ILindaLike support = PlatformExpert.findOutSupport(<ReceiverName>,<messageId>,<SenderName>); <AnswerType> answer=<SenderName>_<OperationName>_<messageId>_<ReceiverName>( M,support ); return answer;

}

Input operation scheme <ReturnType> hl_<ReceiverName>_<OperationName>_<messageId>(){

ILindaLike support = PlatformExpert.findInSupport( <ReceiverName>,<messageId>,<WithAnswer>); <ReturnType> answer=<ReceiverName>_<OperationName>_<messageId>( support );

return answer; }

(5)

An application-specific method starts by calling thePlatformExpert object, so to dynamically find (or build) the right communication run-time support (Section 4); then it calls a corresponding low-level operation –that defines the operational semantics in terms of ILindaLike operations– by giving to it the support to perform the required communication actions. The following table shows the types that can be assumed by the object returned by a Contact ope-ration.

AnswerType ReturnType

void: when no reply is expected by the caller.

IAcquireOneReply: when the caller expects to receive back just one reply.

IAcquireManyReply: when the caller expects to receive one or more reply.

IMessage: when the receiver does not have to send any reply to the caller (see Subsection 4.1).

IMessageAndContext: when the receiver must create and send a reply to the caller.

The objects returned by aContact operation can be used by the application designer to check for the availability of a message or of a reply and to get it.

IMessageAndContext public interface IMessageAndContext {

public void replyToCaller(String msg); public IMessage getReceivedMessage(); }

IAcquireOneReply public interface IAcquireOneReply{

public boolean replyAvailable(); public IMessage acquireReply() ; }

IAcquireManyReply public interface IAcquireManyReply {

public int numOfReplyExpected(); public int numOfReplyReceived(); public IMessage acquireReply(int n); }

ThegetReceivedMessagereturns the received message, while thereplyToCaller sends the reply (ack, answer etc.) to theSubject that has sent that message.

The acquireReply operation is a blocking operation that returns a reply message if it is available. The avai-lability of a message can be tested using the replyAvai-lableoperation.

The availability of a message can be tested using the numOfReplyReceivedoperations, while the numOfRe-plyExpectedreturns the number of reply that could be received.

3 The impact on the production process

This section presents the usage of the Contact language with reference to a (simple) case-study: the definition of a dynamically reconfigurable distributed software system that finds all prime numbers up to a specified integer, using the algorithm known as Sieve of Eratosthenes. The initial system configuration is made of a pipeline of three elements:i) a generator of natural numbers (named intGen) starting from 3; ii) a filter (named filter2) that eliminates all the natural numbers divisible for2andiii)a collector of the prime numbers (named sieve). The logical behavior of the system can be informally described as follows.

Whenfilter2receives fromintGena number not divisible by2(i.e.3) , it sends such a number to thesievethat stores it as a prime number. Moreover,filter2reconfigures the pipeline by creating a new filter that will eliminate all the numbers divisible by 3, working as a new element of the pipeline inserted betweenfilter2and thesieve. In this way, the next number that reaches the

(6)

The behavior logic of a generic filter can be expressed inJava as follows:

FilterN

public class FilterN extends Thread{ protected int myPrime;

protected boolean go = true; protected void execFilterWork() {

while (go) { IMessage m = getInput(); handleInput( m.msgContent() ); }// while }} FilterN: handleInput protected String nextFilter = null; protected void handleInput(String msg){

if (checkEnd(msg)) go = false; else{

int n = Integer.parseInt(msg); if (n % myPrime == 0)

showMsg( "rejects " + n); else if (nextFilter == null){

sendToSieve( ""+n );

nextFilter=createAnotherFilter(n); }else sendToNextFilter( ""+n ); }}

This component is conceived as a finite state ma-chine (FSM) that runs in its ownThread. The state transitions is performed by the local method handleInput according to the informa-tion received in input. ForIMessagesee Subsec-tion 4.1.

Thefilter2component can be logically viewed as an instance offilterN.

Ifmsgdoes not include information to terminate, it represents a natural number (n); ifnis not di-visible for the filter prime number (myPrime) then

nis sent to the next element of the pipeline. If thenextFiltervariable is not bound, the des-tination element is the sieve; in this case, a new instance of (FilterN) is created, and the

nextFiltervariable is bound to the name of such a new filter.

If the nextFilter variable is bound, the

nextFilterbecomes the destination of the next number not divisible formyPrime.

The filterN class defines the relevant part of the ”business logic” of the system; to make things simpler, the designer can reasonably decide that all the instances of the filterNclass belong to the same JVM; in this case the create operation can be defined as follows:

FilterN: createAnotherFilter public String createAnotherFilter( int n ) throws Exception { FilterN filter = new FilterN(n);

filter.start(); return filter.getName(); }

TheFilterNclass is quite easy to implement, once that a proper support for communication is given. But before any implementation, the Contact concep-tual space helps an analyst or a designer to express (and evaluate) different applicative scenarios5.

From the specification to a working prototype

AContact specification is introduced in three steps:i)first the system com-ponents are defined; ii) then the message types are introduced; iii) finally the communication patterns among the components are specified6.

5

If the conceptual space is not adequate, it is time to extend theContactmeta-model.

6 _{In a}_Contact _{specification there is (at the moment) no sentence related to the}

(7)

Subject specification ContactSystem sieveSystem; Subject class filterN ; Subject intGen ; Subject sieve ;

Subject filter2 inherits filterN ; Message specification Signal nextInt ; Dispatch isPrime ; Invitation nextVal ; Request getPrime ; Communication specification intGen emit nextInt ;

filter2 sense nextInt ; filterN accept nextVal ; filterN ask nextVal to filterN ; filterN forward isPrime to sieve ; sieve serve isPrime ;

sieve grant getPrime ;

Definition of the components.

This specification describes the components of the initial configuration of the system, including the fact that the subject filter2can be viewed as a specialization of a more generic entity calledfilterN.

Definition of the types of the messages.

This specification introduces a wide set of message types, so to have an idea of the conceptual space actually sup-ported byContact.

Definition of the communicationsroles.

A set of constrains that describe –with a relational flavor– the logical architecture of the system.

For the sake of simplicity, the datatypes associated to the messages are omitted.

Since most of the communication infrastructure is generated by theContact-ide, the application designer can produce in a very short time a first working proto-type of the system (running on a singleJVM), with the aim of further improving the mutual understanding with the customer.

What the IDE does (see Figure 2). TheContact-ide generates aJava abstract class for each subject. A subject class has the nameSubjSupport–whereSubjis the name of the subject– that extends a predefined abstract Thread named Subject. The application designer must define the application logic into the abstract methoddoJobby designing a proper specific (communication-driven) state transition sequence of the subject viewed as aFSM.

The business logic finds quite rapidly its proper support, by exploiting the generated support classes. Let us start with the methodgetInput.

getInput // FilterN method

protected IMessage getInput() throws Exception{

IMessage m = hl_filterN_accept_nextVal(); //defined in FilterNSupport return m; }

@Override //Filter2 method

protected IMessage getInput() throws Exception{

IMessage m = hl_filter2_sense_nextInt(); //defined in Filter2Support return m; }

The methods offilterNthat send information to the other components are:

FilterN protected void sendToSieve( String ns ) throws Exception{

hl_filterN_forward_isPrime_sieve(ns); //defined in FilterNSupport } protected void sendToNextFilter( String ns ) throws Exception {

IAcquireOneReply m=hl_filterN_ask_nextVal_filterN(ns,nextFilter);//def. in FilterNSupport showMsg( "got " m.acquireReply().msgContent() ); }

To build a first working prototype, the application designer must define a specialized version of each generated subject support. Let us report here a pos-sible version of the remaining applicative classes, by omitting for the moment the fact that thesievemustgrant therequest getPrime(this case will be discussed in Section 4).

(8)

IntGen

public class IntGen extends IntGenSupport{ public IntGen(){ super(); }

public void doJob() {

for( int n=3; n<9; n++) sendNextInt(n); endJob();

}

protected void sendNextInt(int n){ showMsg( " n=" + n );

hl_intGen_emit_nextInt(""+n); }

protected void endJob() { hl_intGen_emit_nextInt("end"); }}

Sieve

public class Sieve extends SieveSupport{ private boolean go = true;

public Sieve() { super(); } public void doJob() {

while( go ){ IMessage m = getInput(); handleInput( m.msgContent() ); }}

protected IMessage getInput(){

IMessage m=hl_sieve_serve_isPrime();return m;} protected void handleInput(String msg){

if (msg.contains("end")) go = false; else{ int n = Integer.parseInt( msg ); } }}

Running the system: TheContact-idegenerates one abstract class for the system as a whole with the nameApplMainwhere Applis the name of the system. TheApplMain class includes the logic required to initialize global system properties, to build common support components and the subjects, to configure the system and to start each subject.

4 From the prototype to a distributed system

Once the first prototype is validated by the customer, the project team can plan the activities required to build a distributed version of the system, for example a version in which thesieve runs on its ownJVMand processor.

The analyst immediately recognizes thatFilter2must communicate in two different ways: initially by interacting with the sieveby using some network protocol; then, after the creation of a new filer,Filter2must interact with the new instance ofFilterNby using the implementation of the sharedSpaceon the common memory, as happens in the first prototype.

The architecture of the system has been designed in such a way that no change is required in the subject application code. The transition from the pro-totype to a distributed system can be made by using adifferent support for the high-level operations to perform; the decision is delegated to thePlatformExpert

component of the Contact runtime. A proper support is automatically created as a consequence of a newContact specification sentence like the following one:

sieve serve isPrime support=TCP [ host=’’137.204.0.1’’ port=8070];

4.1 Co-constructive design

The transition from a system working into a singleJVMto a distributed system cannot be completely transparent to the application logic.7_{The general strategy}

adopted inContact is that the content of a message handled at application level could include also information set by the underlying platform, e.g. an exception-message. However, since distributed systems can pose several problems, the point

7 _{In fact, several things may happen:}_i)_{the attempts to connect with a remote (}_TCP₎

port could fail;ii) a receiver on a port could decide to wait for a limited amount of time only;iii)an expected answer/reply does not arrive (within a prefixed time interval), and so on.

(9)

here is not how they are solved byContact, but that the system designer and the application designer must agree on the best way to make these problems detectable and manageable at application level.

As the result of the co-constructive work between application and system designers, the architecture of a Contact system is always composed of three main layers: i) the applicative layer that implements the business logic; ii) an application-support layer (built by a custom software factory) that provides the set of high-level operations required by the business logic; iii) the Contact

infrastructure layer based on some implementation of ILindaLike(Section 2)8_.

This architecture can be viewed as the result of a conventional design process based on thelayer pattern. In our case however, the interfaces provided by each layer are the result of an explicit modeling action and the implementation code is obtained as aM2Mtransformation based on astack of languages, each expres-sing a meta-model and each associated with its own software factory. At the top of the language stack there isContact, while at the bottom there is a low-level language called corecl that captures the idea that, in order to communicate, two entities must share somemedium (e.g. a shared memory space, a communi-cation network, etc.). Between the two there is the intermediate languagemedcl introduced in Section 2, that defines a set of abstract types of communication operations.

The formal definition of the meaning ofContact is performed in two steps, as shown in Figure 1. The M2MContactToMed transformer is a M2M mapper that translates a Contact into an instance of the medcl meta-language. The M2MMedToCoretransformer is another M2Mmapper that translates amedcl spe-cification into an instance of corecl.

Themsgclmeta-model defines the

Figure 1.M2Mtransformation chain

structure of the message exchanged at intermediate level; at application level, this structure is expressed by theIMessageinterface that follows.

IMessage

public interface IMessage extends IBasicMessage{ public String msgEmitter();

public String msgId(); public String msgContent(); public String msgNum(); }

IBasicMessage public interface IBasicMessage {

public String getMsgName(); public String getMsgContent(); public int getMsgSeqNum(); }

The message interfaces reflect the two layers composing the Contact run-time system and subsume most of the knowledge shared between application and system designers. The application designers can handle the messages by using the IMessage interface only, by ignoring their concrete representation. However, making the structure of messages explicitly visible can improve the understanding of the system and the confidence of application designers in using

8

The implementation on common memory is provided by a class namedLindaLike, while the implementation on a network connection is given by a set of objects orga-nized according to suited design patterns.

(10)

the supports provided by the system designer9_{. For this reason, all the messages}

exchanged within a Contact system are made observable at application level, by using a -o option in the system declaration sentence (e.g. ContactSystem sieveSystem -o). When the -ooption is selected, theContact-ide generates a default observer10that shows that the internal structure of the messages is11:

mmm( channelId(subjectId,msgId,content,msgNum), seqNum )

The message representation supports the different Contact communications forms. The structure of thechannelIdreveals how the sharedSpace –an abstraction that inherently provides many-to-many communications among time-uncoupled subjects– can implement alsoP2PContactmessages (dispatches, invitations, requests). If two subjects nameds1ands2declare to send a message with msgId=m to a same subjectr, conceptually they make reference to a same logical channel with chan-nelId=r m. The channelss1 r mands2 r mare used to ”carry” an answer/reply. A (TCP) network connection is viewed as an alternative communication medium. Since each message describes its own logical connection, a single (TCP) connection can be used to support all theP2Pcommunications among the subjects running on the two connected nodes.

Multi input.

The Figure 2 shows a picture of theContact-idegui for thesieveSystemand the application code of thesieve subject, that handles two kinds of messages: the dispatchisPrime and the requestgetPrime.

The methodsprepareInputand

se-Figure 2.TheContact-ide

lectOneInputare provided by the system designer to reduce the com-plexity of the application code when a subject must manage several pos-sible inputs.

prepareInputbuilds the list of que-ries to be given as argument to se-lectOneInput, that finds a message in the localsharedSpace that uni-fies with one of the queries.

The receiver works as alocalproxy of the sender subject by substitu-ting itself to the real caller; thus the code of a subject is made in-dependent of any network proto-col. This goal is achieved by for-warding the message with a mo-dified emitter name into the local sharedSpace, as shown by the struc-ture of messages.

sieve isPrime(

proxyfilter2,isPrime,3,0)

9 _{Another aspect is the possibility to exploit the}_sharedSpace_{as an internal}

knowledge-base that can be consulted at run time to reason about communications.

10_{An observer can be also defined by the application designer since the}_LindaLike_class

is defined as an observable according to theObserver design pattern.

11_{A message includes the}_subjectId_{of the sender; thus a receiver can communicate}

(11)

5 Related works and conclusions

Software development is a collaborative effort where groups of developers need to maintain (contextual) awareness12of how particular tasks or project artifacts are progressing. Since distributed software development offers several theoretical benefits over collocated settings13_{, a number of tools and models have been}

developed (a survey can be found in [5]) to enhance contextual awareness in distributed software development. For example,IBM Jazz[6] aims at introducing a distributed collaboration environment by providing a real-time platform based on the EclipseIDEfor integrating work across the different phases of a software development lifecycle. The Rational Team Concert (RTC) [7] is a plug-in toJazz that enables contextual awareness by mining relational properties of entities within shared software projects. The relational view of RTCoffers the potential to enhance traceability and the monitoring of the state of different entities within a project.

The main vision behind our work is that an important set of relationships formed during the development of modern distributed software systems is often related to the collaboration between two main roles of developers: application designers andsystem designers; these relationships – both structural and social – are supposed here to be based on direct and indirect links among the artifacts that comprise a model-driven project. In this vision, since software teams often think by means of the models they design and build [5], the conceptual space

related to the meta-models becomes a crucial aspect not only for the common understanding required in every cooperation, but also to achieve an appropriate expressive power during software production.

In this perspective,Contact– the custom language for communication among software componenets discussed in this work – is viewed as a tool able to promote reasoning and cooperation, and the related Contact-ide as an environment able to play an active role in driving cognitive processes in all the phases of a software production: in the analysis phase, to express the interaction implied by the business logic of the problem (abstracting from specific communication supports); in thedesign phase to define (in a technology-independent way) the overall architecture of the system; in theimplementationphase, to improve code readability, modularity and platform independence.

The idea of model-driven cooperation around custom languages requires a deep integration between the concepts of domain-specific language (DSL) with theMDSDapproach and finds an excellent support by theXTexttechnology, foun-ded on the Eclipse ecosystem. As advocated by the proposers of the Projectio-nal Editing concept14 _{[8], in}_Contact _{the abstract representation is considered}

the core definition of a system and the models (expressed as instances of the

12_{A context refers to the set of circumstances or facts that surround a particular event}

or situation, including part of a process with different state transitions.

13_{e.g. shortened time-to-market cycles, more rapid response to customer needs, a more}

effective resource pooling, etc

14_{An alternative to SourceEditing is the idea that the core definition of a system should}

(12)

medclandcoreclmetamodels) are conceptually decoupled from their represen-tation (expressed by theContact specification). templates. Moreover, the stack ofContact meta-models leads to a natural decomposition of a system into a set of layers, each related to a proper (abstract) language and built by a proper software factory. TheContact stack can be used/extended to capture more evo-lute forms of communication (e.g. those proposed by FIPA [9])). The required cooperative work will be inherently related to the organization of the software architecture and based on artifacts built using languages with a well-defined operational semantics. Without understating the concept ofactive externalism

[10], language semantics is considered here an essential requirement to create contextual awareness information useful to initiate contacts among people, to avoid misunderstanding and to improve the organization of the software pro-duction and of the resulting products. The slogan coined by James Hendler for theSemantic Web can be adopted also here:a little semantics goes a long way. One of our possible future works is to investigate how this kind of organization can be supported byJazz and wether it can be profitably included in the ETC project [11].

References

1. Natali, A., Molesini, A.: Towards model-driven communications. In Ardil, C., ed.: World Academy of Science, Engineering and Technology. Volume 64., Rome, Italy, Academic Science Research (2010) 69–80 International Conference on Software Engineering and Technology (ICSET 2010).

2. Stahl, T., Voelter, M.: Model-Driven Software Development. Wiley (2006) 3. Steinberg, D., Budinsky, F., Paternostro, M., Merks, E.: EMF: Eclipse Modeling

Framework, 2nd Edition. Addison-Wesley Professional (2009)

4. The Eclipse Foundation: XText site: Home page.

http://www.eclipse.org/Xtext/(2011)

5. Omoronyia, I., Ferguson, J., Roper, M., Wood, M.: Using developer activity data to enhance awareness during collaborative software development. Computer Sup-ported Cooperative Work - The Journal of Collaborative Computing 18(2009) 509–558

6. IBM: Home page. https://jazz.net/(2011)

7. Krishna, S., Fenstermaker, T.: IBM Rational Team Concert 2 Essentials. Packt Publishing (2011)

8. Merkle, B.: Textual modeling tools: overview and comparison of language work-benches. In: Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion, SPLASH ’10, New York, NY, USA, ACM (2010) 139–148

9. IEEE FIPA Design Process Documentation and Fragmentation: IEEE FIPA Design Process Documentation and Fragmentation Homepage. http://www.pa.icar.cnr.it/cossentino/fipa-dpdf-wg/ (2009)

10. Clark, A., Chalmers, D.: The Extended Mind. The MIT Press (1998)

11. Coccoli, M. Maresca, P., Stanganelli, L.: Enfrocing team cooperation using rational software tools into software engineering academic project. In Coccoli, M., ed.: Eclipse-IT 2010. Volume 90-103., Savona, Italy, Eclipse Italian Community (2010) 69–80 The Fifth Workshop of the Italian Eclipse Community.