we define a _ sociotechnical system _ as one involving interactions between _ autonomous _ social entities such as people and organizations mediated by technical components . by emphasizing the autonomous nature of social entities ,
our definition generalizes over , yet more precisely captures , the traditional connotation of the interaction between humans and societal infrastructure .
our definition contrasts with one of the conventional uses of the term , which covers any interaction between people and computers .
researchers in software engineering ( se ) picked up the theme of sociotechnical systems in two major directions : ( 1 ) how to model a sociotechnical system as a combination of social and software components , as in @xcite ; and ( 2 ) how to elicit , model , and manage the requirements of the social components so that suitable software components may be designed @xcite .
often , there is substantial overlap between the two directions , for example , as in i * @xcite .
baxter and sommerville conceptualize a sociotechnical system as one that _ actively pursues goals _ in an organizational setting ; that is , a sociotechnical system is one actor : a single locus of control
. therefore , we refer to such systems as being _ conceptually centralized_. the centralized conception is shared by current se approaches .    for clarity ,
we reserve the term _ principal _ to refer to an autonomous social party who participates in a system at runtime and the term _ stakeholder _ to refer to one who originates some of the requirements . in general , any principal would also be a stakeholder in the system ( suitably abstracted via the notion of _ roles _ ) .
we restrict our attention to systems whose membership and structure can change dynamically .
open _ sociotechnical systems are properly viewed as _
societies _ of principals : we can not build a `` complete '' system but can only specify how its members may _ interact _ , leaving as out of our scope the engineering of the members themselves .
thus whether the members _ comply _ with the specified interactions is crucial . because of its emphasis on interaction , we term our approach interaction - oriented software engineering or _
iose_. we claim that iose is necessary and show that the centralized conception is not applicable in sociotechnical systems .
common settings such as business services and social computing realize open sociotechnical systems .
consider schield et al.s description of a healthcare system in the united states , including its key stakeholders and their ( presumed ) objectives .
* us society : the collective public , private , and personal interests of the united states citizens .
* regulatory bodies : public and private that make and enforce policies . * mco : managed care organizations ( i.e. , licensed insurance organizations ) , who offer and administer managed care plans .
* institutional providers : hospitals and laboratories .
* clinical or professional providers : individual doctors and communities of practice .
* employers : fully insured and self - funded organizations who offer managed care plans to their employees . * consumers : the enrollees of managed care plans . * medicaid or medicare beneficiaries .
schield et al .
find that the stakeholders objectives often conflict .
for example , payers must keep costs down whereas providers must maximize revenue ; insurers want to shift risk to providers and consumers for matters of cost control whereas both providers and consumers want protection from potentially catastrophic costs .
consumers want shorter waiting periods for appointments with their physicians whereas physicians want to increase their panel of patients .
further , schield et al .
point out how one principal can , in pursuing its own objectives , compromise the objectives of others . for example , making a patient wait longer may compromise the patient s health , thereby increasing the cost of care and decreasing patient satisfaction .
regulatory bodies have the objective of making sure mcos and providers play by the rules and ensuring that cost , quality , and access criteria are met but that conflicts with society s goals of lower - cost healthcare .
assume that the stakeholders for a healthcare system manage to resolve their differences and specify a system that meets their stated collective requirements .
now , individual _ principals _ such as specific mcos , hospitals , physicians , employees , and consumers can join or leave the managed healthcare system of their own volition .
the principals act according to their own private business policies , some of which may not have been envisaged by the stakeholders .
for example , an mco may have a private objective to acquire an independent call center .
further , principals would generally employ their own internal information systems to support their interactions with other principals .
for example , providers may set up appointment systems to handle appointment - related communications with consumers .
hospitals and mcos may use complex information systems that help process payments from each other and the consumers .
mcos may employ complex actuarial and decision - support processes in handling claims .
recognizing and addressing conflicts among stakeholders requirements has been a longstanding area of research in software engineering .
once the conflicts are addressed , through whichever means , engineers would seek to model and realize a system that meets those requirements .
this paper treats conflict analysis as out of scope and instead focuses on identifying modeling assumptions and criteria that capture sociotechnical systems more faithfully .
this paper makes two main contributions .
first , it shows via conceptual analysis why iose is ( 1 ) a novel paradigm and ( 2 ) well - suited for the software engineering of open sociotechnical systems .
our argument proceeds as follows .
one , we show that the foundational models of traditional se are conceptually centralized .
this is because traditional se concerns itself with the engineering of what is conceptually a single machine ( section  [ sec : machine - orientation ] ) .
two , we present the conceptual model of a system in iose ( section  [ sec : iose ] ) and discuss how it accommodates multiple perspectives .
three , based on the characteristics of sociotechnical systems , namely , autonomy , accountability , and loose coupling , we formulate criteria that any se approach for them should meet and show that whereas machine - orientation , and therefore traditional se , fails the criteria , iose meets them ( section  [ sec : eval - machine - iose ] ) .
the second contribution of this paper lies in reinterpreting the broad se principles of modularity , encapsulation , abstraction , and the separation of concerns in accordance with the above criteria ( section  [ sec : principles - iose ] ) .
the reinterpretation provides the elements of a methodology for iose .
further , we discuss in detail well - known software methodologies that are motivated either by sociotechnical systems or the modeling of interactions among principals and show how they violate one or more of these principles ( section  [ sec : prominent - approaches ] ) .
section  [ sec : literature ] discusses additional literature that is relevant to iose .
section  [ sec : discussion ] concludes the paper with pointers to future directions .
figure  [ fig : re - conceptual - model ] ( from van lamsweerde ) shows the traditional conceptual model for se .
the _ system as is _ represents the system with identified problems , inefficiencies , and limitations .
the _ system to be _ , whose _ objectives _ are to avoid those deficiencies , is to be engineered .
the idea is to understand the problem domain in order to come up with a set of _ services _ , _ constraints _ , and _ assumptions
_ under which the stated objectives would be met
. some of these would be met by the _ software to be _ as part of the system to be ; the rest would be assigned as responsibilities to components in the _ environment _ , namely , _ people _ , _ devices _ , and _
existing software_.    = [ blue!40!black , font= * * ] = [ font= ] = [ align = center ] * *    = [ draw , rectangle , align = center , minimum height=5ex , text width=8ex ]    ( why ) at ( 0,5.5 ) why ? ; ( what ) at ( 0,3.2 ) what ? ; ( who ) at ( 0,0 ) who ? ;    ( cloud ) at ( 7.0,5.75 ) objectives ;    ( core ) at ( 2.4,5.55 )    [ cols="^ " , ]     ;    background ( lbl.north-| e.east ) rectangle ( p.south-| p.west ) ;    even more generally , given a set of requirements , the essential idea is to come up with the specification of a _ machine _ ( equivalently , the software to be above ) that along with reasonable domain assumptions satisfies the requirements of the stakeholders @xcite .
the _ system as is _ is the system as it exists without the machine and helps us understand the environment in which the machine will be introduced .
the system to be is what the system will be when the machine is introduced .
if all goes well in the system to be , the stakeholders requirements are satisfied .
it is important to understand the nature of the machine .
figure  [ fig : machine - environment ] ( from @xcite but based on @xcite ) illustrates an operational conceptualization of the machine - environment interface . here , the _ software to be _ represents the machine .
a machine is a _ controller _ that maps inputs from its environment ( by monitoring certain variables ) to outputs or effects in the environment ( by setting certain variables ) . in other words , it processes inputs to produce outputs . to its users ( in the environment ) ,
a machine provides computational services ( functionality ) .    in its very conception
, a machine corresponds to a single locus of control .
indeed , it is common in software engineering to talk of machines as acting in pursuit of goals @xcite .
traditional se is machine - oriented  it concerns itself with the specification of a machine ( even if implemented via distributed components ) that would meet stakeholder requirements .
thus traditional se reflects a _ conceptually centralized _ perspective , namely , of the stakeholders , considered collectively .
= [ thick , draw = none , text width=15ex , align = center ] = [ box , fill = blue!20!gray!40 ] = [ box , fill = black!10 ] = [ box , draw = black , thin , fill = white , text = black ]    = [ blue!40!black , draw = none , text width=10ex , align = center ] = [ font= ] = [ align = center ]    ( machine_envt ) [ draw = none , row sep=1 mm , column sep=3 mm ] ( empty - tl ) ; & ( input ) input devices + ( sensors ) ; & ( empty - tr ) ; + ( environment ) environment ; & & ( software ) software to be ; + ( empty - bl ) ; & ( output ) output devices + ( actuators ) ; & ( empty - br ) ; + ; ( environment ) .. controls ( empty - tl ) .. node [ edge_label , above ] monitored + variables ( input ) ; ( input ) .. controls ( empty - tr ) .. node [ edge_label , above ] input + data ( software ) ; ( output ) .. controls ( empty - bl ) .. node [ edge_label , below ] controlled + variables ( environment ) ; ( software ) .. controls ( empty - br ) .. node [ edge_label , below ] output + data ( output ) ;    the above account of machine - orientation , taken from leading writings on se , is agnostic to particular software methodologies .
machine - orientation manifests itself in specific modeling notations and methodologies , some of which have been highly influential in se .
many existing requirements - based approaches , although differing in their details , instantiate the same concepts at their core : machine , environment , system as is , and system to be .
tropos @xcite and i * @xcite refer to a model of the system as is and the system to be as the early and late requirements models , respectively . in their terminology ,
the environment is a set of _ actors _ ; the machine itself is the _ system actor_. for example , tropos would create a system actor for an entire healthcare system .
this actor would capture ( a consistent subset of ) the goals of all stakeholders , thereby functioning as a logically centralized machine .
following kaos @xcite , one would create a set of _ agents _ with designer - assigned individual goals .
however , the set of agents is conceptually a single machine because there is a single locus of design .
this follows from the fact that goals are assigned to agents and , therefore , at a high - level the agents have already been specified . indeed , referring specifically to kaos ( and to feather s work , which provides the conceptual basis for kaos ) , zave and jackson observe that even though kaos supports multiple agents , it is only a refinement of their more basic single - machine framework .
let us apply the above conceptual model of systems to the healthcare scenario .
imagine that a healthcare machine were built to a specified set of stakeholder requirements .
the machine would control various medical devices and other equipment .
users such as consumers , providers , mcos , and so via on would interface with the machine via a web interface .
consider the example of scheduling an appointment with a physician .
the physician would have configured his or her preferences in the machine : his or her daily schedule , how long a time period to allot each patient , and so on .
those are the physician s inputs to the machine , which the machine uses in scheduling patient appointments .
the patient s interface would display the available slots and enable him or her to choose from among those slots .
the machine records each selection , and produces as output a confirmation of the appointment , perhaps also by email .
further , the machine grays out the slot for future scheduling .
the machine additionally supports the processing of claims and payments among hospitals and insurers . the machine would encode the insurance company s process of queuing claims above $ 10,000 separately for detailed examination .
the insurance company through its interface can obtain the claims from the appropriate queues .
the machine would implement the appropriate access control so that users can access the appropriate functionality .
traditional se , in spite of its conceptually centralized perspective , may be applied to yield a physically distributed machine .
web applications suggest physical distribution and applying kaos would result in a physically distributed set of agents . in general , techniques from software architecture
may be applied to internally decompose a machine into distributed components .
rapanotti et al .
employ such an approach in the decomposition of machines in the problem frames approach .
we define a _ protocol _ of a sociotechnical system as a specification of how interactions among its roles would proceed . in business settings , the protocol can take the form of a business contract that principals would enter into upon adopting different roles .
for example , in texas , if medco wishes to play the role of mco , it must enter into a _
uniform managed care _
contract with the state health commission ( which alone plays the regulatory body role ) @xcite .    at any point during the interaction , the set of social expectations represents the _ social state _ of the system .
a protocol serves three purposes .
one , it makes public the social expectations of the participants while giving them the flexibility to follow their individual objectives .
for example , public funding agencies may expect that mcos , upon notification , refund payments made in error within 30 days .
two , it identifies which participant is accountable to which participant for what expectation . for instance , if medco , who plays mco , does not refund an erroneous payment in time , the funding agency may hold medco accountable .
three , it frees participants to implement their information systems as they please as long as they satisfy the given protocol .
for example , medco might employ any representation it chooses and may apply its policies in deciding whether to provide a refund early or late within the 30-day window .
= [ thick , draw = none , text width=11ex , align = center ] = [ box , fill = green!10!blue!30!gray!60 ] = [ box , fill = black!10 ] = [ box , fill = green!10!blue!30!gray!40 ]    = [ box , draw = black , thin , fill = white , text = black ]    = [ blue!40!black , draw = none , text width=10ex , align = center ] = [ font= ] = [ align = center ]    ( machine_envt ) [ draw = none , row sep=1 mm , column sep=3 mm ] ( environment - l ) environment ; & & & ( environment - r ) environment ; + & ( empty - top - l ) ; & ( empty - top - r ) ; + ( empty - principal - l ) ; & (
principal - l ) principal ; & ( principal - r ) principal ; & ( empty - principal - r ) ; + ; + ( empty - ml ) ; & ( role - l ) role ; & ( role - r ) role ; & ( empty - mr ) ; + ; + & ( empty - bcl ) ; & ( empty - bcr ) ; + ; ( sociotechnical system ) sociotechnical system as protocol ;    ( protocol )   + meanings ;    ( principal-l.south ) .. controls ( protocol.south ) .. ( principal-r.south ) ;    ( environment-l.south ) .. controls ( empty - principal - l ) ..
( principal-l.west ) ; ( environment - r ) .. controls ( empty - principal - r ) .. ( principal - r ) ;    background ( empty - top - l.north-| principal-r.east ) rectangle ( protocol.south-| principal-l.west ) ;    accordingly , the objective of iose is to specify a _ sociotechnical system _ as a protocol that defines two or more _ roles_. figure  [ fig : system ] describes how iose applies . for the sociotechnical system
to be instantiated , principals adopt roles in the protocol .
each principal continues to interact with its environment even after it joins the system .
the principals communicate with each other within the scope of the system , which means that they are subject to the meanings defined in the protocol that specifies the system . in engineering terms , the main artifact produced by iose is the protocol which , through its roles , itself serves as a requirement for the principals who would adopt those roles .    whereas traditional se seeks to specify a machine , iose seeks to specify a protocol .
whereas a machine captures a single locus of control , iose naturally supports multiple perspectives as roles in a protocol . in iose , each principal , who adopts one or more roles , is a locus of control  a reasoner and a sender and receiver of communications .
we introduce commitment protocols @xcite as an example iose approach . a ( social ) commitment captures an elementary business relationship between a debtor and a creditor @xcite .
specifically , the commitment @xmath0 says that the debtor @xmath1 commits to the creditor @xmath2 that if the antecedent @xmath3 comes to hold , then it will bring the consequent @xmath4 .
the elementary operations on commitments are create , release , cancel , delegate , and assign .
the social nature of commitments owes to the fact that they progress due to interactions among principals , not due to the internal reasoning of any principal .
commitment protocols exploit this connection by specifying the meanings of _ messages _ in terms of how they affect commitments , thus enabling principals to interact flexibly .
other abstractions could potentially be used in addition to commitments but , for simplicity , we confine the present discussion to commitments .
table  [ table : scheduling - protocol ] shows a partial appointment scheduling protocol .
the protocol involves two roles , phy ( for physician ) and pat ( for patient ) .
assume that via the enactment of some other protocol , ( any physician playing ) phy is committed to ( any patient playing ) pat to provide the latter with a list of available appointment slots upon the latter s request for appointment ( this commitment , for instance , could be set up when a patient registers with a physician for the first time ) .
we represent this commitment as @xmath5 .
the availableslots message from phy to pat conveys the list of available slots to the pat : it means that phy commits to pat that if pat commits to show up for one of those slots , then phy will commit to showing up for that slot as well .
the select message from pat to phy commits pat to a selected slot .
the confirmslot message from phy to pat for a particular slot commits phy to the slot .
a complete and effective meeting scheduling protocol would additionally include messages that deal with meeting cancellation and rescheduling .
figure  [ fig : ms - progression ] depicts the progression of social state according to the meanings in table  [ table : scheduling - protocol ] and using the commitments introduced in table  [ table : scheduling - protocol - commitments ] .
alessia plays phy and bianca plays pat . upon bianca sending the requestappointment message to alessia
, the antecedent of @xmath6 is satisfied .
this makes alessia unconditionally committed to sending her the available slots ( @xmath7 ) .
when alessia sends the list of available slots ( at 1400 and 1600 hours ) , she discharges @xmath7 and creates @xmath8 .
bianca communicates her selection of 1400 , which makes alessia unconditionally committed to confirming it ; in other words , bianca creates @xmath9 , which creates @xmath10 ( the unconditional version of @xmath8 ) . finally , alessia confirms the selected slot , thus creating @xmath11 and discharging @xmath10 . in the final state of figure
[ fig : ms - progression ] , both alessia and bianca are committed to each other for showing up at the selected time .
= [ thick , draw = none , text width=7ex , minimum height=7ex , align = center ] = [ box , fill = green!10!blue!30!gray!60 ]    = [ blue!40!black , auto = true , font= ] = [ edge_label , fill = white , auto = false ] ( soc-1 ) [ draw = blue!20!black , row sep=25 , column sep=0 ] ( alessia-1 ) alessia + mi ; + ( bianca-1 ) bianca + mp ; + ; ( soc-2 ) [ draw = blue!20!black , row sep=25 , column sep=0,right of = soc-1 ] ( alessia-2 ) alessia + mi ; + ( bianca-2 ) bianca + mp ; + ;    ( soc-3 ) [ draw = blue!20!black , row sep=25 , column sep=0,right of = soc-2 ] ( alessia-3 ) alessia + mi ; + ( bianca-3 ) bianca + mp ; + ;    ( soc-4 ) [ draw = blue!20!black , row sep=25 , column sep=0,below of = soc-3,left of = soc-3,node distance=90 ] ( alessia-4 ) alessia + mi ; + ( bianca-4 ) bianca + mp ; + ;    ( soc-5 ) [ draw = blue!20!black , row sep=25 , column sep=0,left of = soc-4 ] ( alessia-5 ) alessia + mi ; + ( bianca-5 ) bianca + mp ; + ;    ( alessia-1.south ) to node [ edge_label_in ] @xmath12 ( bianca-1.north ) ;    ( alessia-2.south ) to node [ edge_label_in ] @xmath13 ( bianca-2.north ) ;    ( alessia-3.south ) to node [ edge_label_in ] @xmath14 ( bianca-3.north ) ;    ( alessia-4.240 ) to node [ edge_label_in ] @xmath15 ( bianca-4.120 ) ; ( bianca-4.60 ) to node [ edge_label_in ] @xmath16 ( alessia-4.300 ) ;    ( alessia-5.240 ) to node [ edge_label_in ] @xmath17 ( bianca-5.120 ) ; ( bianca-5.60 ) to node [ edge_label_in ] @xmath16 ( alessia-5.300 ) ;    ( soc-1.east ) to node [ pos=0.5,edge_label_in ] requestappointment ( ) ( soc-2.west ) ;    ( soc-2.east ) to node [ pos=0.5,edge_label_in ] availableslots(1400,1600 ) ( soc-3.west ) ;    ( soc-3.south ) to node [ pos=0.5,edge_label_in , xshift=10 ] selectslot(1400 ) ( soc-4.east ) ;    ( soc-4.west ) to node [ pos=0.5,edge_label_in ] confirmslot(1400 ) ( soc-5.east ) ;    protocols for handling claims between providers and mco would be more complex than those for appointment scheduling .
desai et al .
specify protocols for automobile insurance and show how to compose protocols .
we focus on appointment scheduling because ( 1 ) it illustrates the essential concepts of iose , and ( 2 ) it bears similarity to meeting scheduling , an application that has been studied extensively in the literature , and which we discuss in detail in section  [ sec : prominent - approaches ] .
figure  [ fig : system - types ] describes three takes on a sociotechnical system . figure  [ fig : old ] shows the most traditional setting , which even predates it . here
, one can imagine a sociotechnical system as realized by two or more principals , each with its own ledgers , and interacting via the postal service or foot messenger .
the principals are autonomous .
the same situation holds in the case of digital communication , where we can think of the messaging system as providing the necessary message delivery functionality . in this case too , the messages the principals send and receive are opaque to the communication network . in either case , there is no computational support for the social state .
indeed , there is no computational support for anything beyond message transport and , possibly operational constraints such as message ordering .
each principal maintains its expectations and commitments in its ledgers and acts according to its local policies .
for example , a physician may send a request to a laboratory to find a patient s cholesterol and the laboratory may send back the results along with an invoice .
= [ thin , draw , align = center , anchor = center , minimum height=20,inner sep=2pt , font= ]    = [ box , fill = blue!20!gray!20,draw = none , minimum height=6ex , rounded corners ]    = [ box , draw = none , circle , fill = green!10!blue!30!gray!60,minimum width=6 ]    = [ shape = cloud , align = center , thick , aspect=4,fill = green!10!blue!30!gray!40 ]    = [ blue!40!black , draw = none ] = [ annotation , midway , anchor = south , align = center ]    = [ align = center ]    = [ anchor = base east ] = [ anchor = base east ]    0.3    ( trust ) [ draw = none , matrix of nodes , row sep=10,column sep=0 ] ( xx ) ; & [ 35]&[35 ] ( yy ) ; + ( empty - tl ) ; & & ( empty - tr ) ; + ( empty - ml ) ; & & ( empty - mr ) ; + ( empty - bl ) ; & & ( empty - br ) ; + ;    let 1 = ( xx.west ) , 2 = ( yy.east ) , 3 = ( empty-bl.south west ) , 4 = ( empty - ml ) in node ( bl ) at ( 1 + 0,3 ) node ( br ) at ( 2 - 0,3 ) node ( tl ) at ( 1 + 0,4 - 10 ) node ( tr ) at ( 2 - 0,4 - 10 ) ;    node [ activity , fit= ( bl ) ( br ) ( tl ) ( tr ) ( empty-bl.south ) ( empty-br.south),inner sep=0,minimum height=40 ] ( communication ) ;    let 1 = ( communication.west ) , 2 = ( communication.east ) , 3 = ( communication.north ) in node [ font=,draw = none , align = center , minimum height=40,anchor = north ] at ( 3,3 - 0 )   + ;    ( yy.south ) |-(yy.south|-communication.center)-| ( xx.south ) ;    0.3    ( trust ) [ draw = none , matrix of nodes , row sep=10,column sep=0 ] ( xx ) ; & [ 35]&[35 ] ( yy ) ; + ( empty - tl ) ; & ( empty - tr ) ; + ( empty - ml ) ; & ( empty - mr ) ; + ( empty - bl ) ; & & ( empty - br ) ; + ;    let 1 = ( xx.west ) , 2 = ( yy.east ) , 3 = ( empty-bl.south west ) , 4 = ( empty - ml ) in node ( bl ) at ( 1 + 0,3 ) node ( br ) at ( 2 - 0,3 ) node ( tl ) at ( 1 + 0,4 - 10 ) node ( tr ) at ( 2 - 0,4 - 10 ) ;    node [ activity , fit= ( bl ) ( br ) ( tl ) ( tr ) ( empty-bl.south ) ( empty-br.south),inner sep=0,minimum height=40 ] ( communication ) ;    let 1 = ( communication.west ) , 2 = ( communication.east ) , 3 = ( communication.north ) in node [ font=,draw = none , align = center , minimum height=40,anchor = north ] at ( 3,3 - 0 )   + ;    ( xx.south ) to node [ edge_label , right ] api ( xx.south|-communication.north ) ;    ( yy.south ) to node [ edge_label , left ] api ( yy.south|-communication.north ) ;    0.3    ( trust ) [ draw = none , matrix of nodes , row sep=10,column sep=0 ] ; & ( social ) ; & ; + ( xx ) ; & & ( yy ) ; + ( empty - tl ) ; & [ 70 ] ( empty - tr ) ; + ( empty - ml ) ; & & ( empty - mr ) ; + ( empty - bl ) ; & & ( empty - br ) ; + ;    let 1 = ( xx.west ) , 2 = ( yy.east ) , 3 = ( empty-bl.south west ) , 4 = ( empty - ml ) in node ( bl ) at ( 1 + 0,3 ) node ( br ) at ( 2 - 0,3 ) node ( tl ) at ( 1 + 0,4 - 10 ) node ( tr ) at ( 2 - 0,4 - 10 ) ;    node [ activity , fit= ( bl ) ( br ) ( tl ) ( tr ) ( empty-bl.south ) ( empty-br.south),inner sep=0,minimum height=40 ] ( communication ) ;    let 1 = ( communication.west ) , 2 = ( communication.east ) , 3 = ( communication.north ) in node [ font=,draw = none , align = center , minimum height=40,anchor = north ] at ( 3,3 - 0 )   + ;    \(xx ) to node [ edge_label , anchor = north ] protocol ( yy ) ;    ( yy.south ) |-(yy.south|-communication.center)-| ( xx.south ) ;    ( social.south ) |-(social.south|-xx.east ) ;    figure  [ fig : machine ] shows a more sophisticated , but traditional , approach wherein a machine mediates all interactions among the principals .
the machine offers an api to the principals through which they can request changes in the social state . such conceptually centralized machines are not common for healthcare today , so we use ebay as an example and then return to healthcare .
the auctioneer ebay offers a machine for conducting auctions that provides an api ( requiring little more than a web browser ) through which sellers can list items for sale and buyers can bid for listed items .
the machine determines the social state : whether something is on sale , its reserve price , the time an auction closes , whether a bid is legitimate , the winning bid , and so on .
the principals can represent their local view in their ledgers but what matters is the ebay machine s view .
the machine happens to usually respect the requests of buyers and sellers but it does not need to .
returning to the healthcare machine of section  [ sec : machine - orientation ] , the patient may attempt to schedule an appointment with the physician , but the machine determines whether the appointment holds , i.e. , whether the patient and physician are each committed to showing up at the appointed time . the patient and
the physician may maintain their local views of the social state but what the machine maintains is definitive .
the same situation arises between the hospital and medco regarding their payments . in this setting ,
the only way the parties can interoperate is if they maintain their local views tightly synchronized with the central machine .
in contrast , figure  [ fig : iose ] shows how the principals enact a protocol with one another .
the enactment takes advantage of infrastructure such as for communication .
however , the social state is determined not by the infrastructure but through the enactment of the protocol .
that is , the protocol specifies how the social state progresses . here
too the principals can maintain their individual ledgers but what the protocol specifies is definitive .
the important challenge of formalizing protocols to ensure that the local views remain sufficiently consistent with the protocol - specified `` public '' state without synchronization is out of our present scope .
chopra and singh present a relevant approach .
let us use the healthcare example of section  [ sec : healthcare ] to motivate the key criteria that any software engineering methodology for sociotechnical systems must support .
accommodate autonomy the autonomy of a principal ( a human , organization , or other social entity ) means that it is an independent locus of control with its own goals and policies , which reflect its business motivations and are normally private . thus even as a participant in a system , each principal is free in principle to act in pursuit of its own goals , without any consideration of others .
for example , a hospital may decide not to entertain patients with a particular insurance provider , or physicians may increase the panel of patients they treat at the expense of reducing availability .
figure  [ fig : old ] is compatible with autonomy only to the extent that it does not model social state .
figure  [ fig : machine ] violates autonomy because the machine not only determines the definitive social state but also controls transitions on it .
the principals have no direct relationship with each other .
for example , a bid may be declined and a seller may not be able to change his mind and accept a bid lower than the reserve price .    contrast the above with protocols .
a protocol is not a computationally active entity and can not provide a service .
a protocol simply specifies the correctness criteria for interaction among the participants .
figure  [ fig : iose ] expresses a protocol that specifies the appropriate social relationships among potential principals , capturing their legitimate expectations of each other .
further , principals would enter into these relationships of their own volition ; no relationship is forced upon a principal , not even to ensure compliance .
support accountability accountability is the flip side of autonomy .
a participant is free to act as it pleases ; however , it is accountable to those that have legitimate social expectations of it .
for example , a laboratory may legitimately expect that the mco transfer funds for services provided within a certain time after submission of claims .
this means that the mco is accountable to the laboratory for transferring funds in time ; if it does not , it violates the laboratory s expectation .
figure  [ fig : old ] provides no support for accountability because it does not represent the social state .
figure  [ fig : machine ] holds each principal accountable to the central authority and , if it permits , to the other principals . for example , a buyer is accountable to ebay to pay in time .
but if she persuades ebay to grant her an extension , the seller has no recourse within the ebay system .
figure  [ fig : iose ] bases accountability on a protocol and thus each principal is accountable to any other principal in whom it has created a legitimate expectation . in particular , through the protocol , each principal ought to be able to judge the compliance with its expectations of each principal with whom it interacts .
accommodate loose coupling loose coupling captures the idea that each principal is an independent locus of design .
it has full control over the design of its own information systems but no control over the design of other principals information systems .
for example , a hospital may store information about a surgeon s willingness to work the night shift whereas the insurance company may capture the total charges for procedures led by that surgeon . and , hospitals in different jurisdictions may capture different patient monitoring data during a surgery .
figure  [ fig : old ] is compatible with loose coupling insofar as it elides the treatment of social state . in practice , it forces an ad hoc design of the interaction ( e.g. , message formats ) . because the message meanings are hidden , the principals who adapt their information systems risk failing interoperability .
figure  [ fig : machine ] requires that the principals adopt the same representation of the social state as the machine .
the meanings of the messages sent over the api could be explicit but they usually are hardcoded in the machine , and sometimes in the principals information systems , if any .
this produces a tighter coupling than desirable between the principals and the machine ( both considered as endpoints ) : when the machine changes , the principals must potentially change their own behaviors and any information systems that support them accordingly .
by contrast , figure  [ fig : iose ] employs a protocol with explicit meanings ( not hardcoded in any principals information system ) for the interactions .
the iose approach , in effect , makes public the extent of the coupling
. the principals may adapt their information systems without consideration of others as long as they follow the protocol .
we introduce the core principles of iose . specifically , we contrast how the key principles of se : modularity and encapsulation @xcite , separation of concerns @xcite , and abstraction are manifested in current modeling approaches with how they are manifested in iose .
we find that although the intuitions behind the principles hold , the technical details are completely different and , in many cases , antithetical to what we encounter in conventional se .
modularity refers to the functional , most commonly hierarchical , decomposition of systems @xcite .
the benefit of appropriately modularizing systems is composability . in the extreme ,
modules from different vendors may be composed as needed .
as figure  [ fig : machine - environment ] shows , the first - level application of modularity in se is the decomposition of the system into the environment and the machine .
rapanotti et al .
apply architectural patterns to decompose a problem frame into its constituent problem frames .
kaos , i * , and tropos , being agent - oriented , support finer grained units of modularity .
the agents therein may have responsibilities or provide services , as captured by the dependencies among them .    in iose ,
a principal as an autonomous social entity is the natural unit of modularity . with autonomy
comes accountability , as motivated by mamdani and pitt . without the ability to check compliance , though , accountability would be meaningless .
_ example .
_ although bianca is free to not show for the appointment once she commits to a slot , she is accountable for her commitment
.    _ benefit .
_ promotes autonomy by not unduly restricting a principal s course of action . promotes accountability by providing a basis for ensuring _ correctness _ : a principal who does not comply may face sanctions from principals to whom it is accountable for the given expectation
each principal autonomously becomes the debtor of any commitments @xcite .
that is , the debtor must have initiated an interaction ( sent a message ) that leads to it being committed . in some cases
, the message could itself create the commitment .
in other cases , the debtor may have created some commitment ( as debtor ) whereby actions by other parties could lead to the creation of the given commitment .
because commitments are created ultimately due to the communications of the debtor , the debtor is accountable for them .
demands placed on a principal other than as the debtor of a commitment have no bearing on compliance or enforcement .
abstraction refers to the level of the concepts used in a specification .
the ideal abstraction is sufficiently high - level to hide details and reduce complexity , yet sufficiently low - level to support drawing the necessary conclusions .
tropos and i * offer high - level abstractions such as goals , capabilities , and goal dependencies .
sommerville et al .
apply high - level notions of responsibility and delegation to requirements modeling .
using high - level abstractions places requirements away from low - level notions such as tasks , plans , and state machines .
in contrast , iose emphasizes abstractions that capture the meaning of an interaction .
explicit social meaning make all social expectations explicit in the system specification .
the meanings of individual communications must be explicitly formalized in terms of what they _ count as _ in the society being designed .
in general , the meaning involves the creation or other manipulation of the commitments among the parties involved .
_ example .
_ table  [ table : scheduling - protocol ] specifies the message meanings in an appointment scheduling protocol .
_ benefit .
_ explicit social meaning promotes loose coupling .
as figure  [ fig : ms - progression ] illustrates , the meaning captures how the principals social state progresses .
the true social state progresses even if we have no computational representation of it . but
lacking an explicit meaning , each principal could interpret messages in incompatible ways .
for example , in the healthcare setting , a laboratory may interpret the messages with the claim information as leading to an unconditional commitment from the mco to honor the claim .
the mco , however , may interpret the commitment as being conditional on the claim being valid .
such misalignments could have serious repercussions for the principals ( e.g. , in producing their balance sheets ) and may lead to legal disputes . if the principals negotiate the meanings of the messages and hard - code them in their information systems , they would produce hidden couplings among themselves : changes in how one principal handles messages would need to be propagated to the others .
additionally , explicit social meaning promotes accountability because if the meanings are public , then principals can potentially check the compliance of themselves and others .
solely social meaning a system specification must specify _ only _ the possible communications and their meanings and nothing else .
further , the meaning must be expressed in terms of social abstractions such as commitments .
specifications of any operational details that have significance at the social level ( e.g. , a convention to pay first ) , must be captured via social abstractions ( e.g. , commitments ) .
specifications that capture ordering and occurrence constraints separately from the meaning violate this principle . for example , one could specify in the appointment scheduling protocol that availableslots follow requestappointment . but here no one is accountable for the constraint : is the physician at fault for not delaying sending availableslots or is the patient at fault for not sending requestappointment ? instead
, if this constraint is necessary as a social requirement , one or more of the principals should commit to enforcing it , e.g. , adopting marengo et al.s approach and placing temporal constraints in commitments .
further , specifying the technical infrastructure does not capture a sociotechnical system .
we might either model the social actor who provides the infrastructure and engage it via commitments or omit such technical constraints altogether since they apply at a lower level of abstraction .
_ example .
_ the above ordering constraint can be expressed @xcite as @xmath18 where the dot ( ` @xmath19 ' ) means
_ occurs before_.    _ benefit .
_ promotes autonomy and accountability .
no central controller enforces constraints in a sociotechnical system .
every constraint logically ought to be some principal s responsibility . expressing a constraint as a hard constraint to be enforced magically by the environment either under -
specifies the functioning of the system or ( in most current thinking ) postulates a central entity that is the sole autonomous principal and can impose its will upon all the other participants .
separation of concerns refers to the treatment of each aspect of a problem independently of _ yet _ in relation to others .
it refers to the sorting out of the different threads from what would otherwise be a tangled mess . often , the invocation of this principle is implicit .
for example , zave and jackson s identification of domain assumptions , machine requirements , and user requirements as the separate but essential categories for re is at its heart an application of this principle .
dardenne et al . and
yu express early requirements in the form of goal models , thus separating the exploration of the problem space from the solution space .
mylopoulos et al .
separate nonfunctional from functional requirements .
finkelstein et al .
separate concerns explicitly based on stakeholders , acknowledging the fact that , in general , each stakeholder has different concerns and may employ different representations for expressing them .    for sociotechnical systems , we must separate social and technical considerations .
principals such as people and organizations must be distinguished from technical entities such as resources , legacy systems , software components , devices , communication infrastructure , and other technical objects in the environment .
this is because social relationships are meaningful only among principals .
a principal may only bear a control relationship ( e.g. , ownership , invocation , or access ) toward a technical entity as may one such entity toward another .
only principals are autonomous and accountable : a patient can not sue an operating table but can sue a surgeon or a hospital .
_ example .
_ as figure  [ fig : ms - progression ] shows , alessia and bianca maintain a social relationship
. however , each of them maintains and controls an information system , which is not socially visible .
_ benefit .
_ separating the social and technical entities makes clear the kinds of relationships that would make sense among them .
promotes accountability by making clear only principals are accountable to each other in the social sense . enables engineers of sociotechnical systems to focus solely on the social aspects .
encapsulation refers to the principle that a module reveal no more information than is necessary to effectively use it , in particular , that it reveal no implementation details .
figure  [ fig : machine - environment ] highlights the interface between the machine and the environment but does not bind the machine to any particular internal implementation . zave and jackson characterize re as the process by which you arrive at the machine - environment interface ; anything more would amount to prematurely determining an implementation . in i * and tropos , dependencies among actors correspond to their interfaces .
the idea of encapsulation , namely , to avoid examining the internals of a component , remains appropriate in iose .
a direct consequence of this principle is that a sociotechnical system can not be specified in terms of mental abstractions such as beliefs , goals , intentions , and so on  neither of its stakeholders nor of the principals who may participate in it .
in particular , roles can not be specified in terms of mental abstractions . in iose , each role in a protocol refers only to the social commitments resulting from the communications that a principal adopting it would be involved in .
_ example .
_ neither the phy role nor the pat role has goal of scheduling appointment ; neither do they have a shared ( joint ) goal to schedule appointments .
_ benefit .
_ promotes loose coupling by hiding details not relevant to the interaction . also promotes accountability : a key reason we can not use mental concepts to specify a sociotechnical system is that they make determining compliance impossible @xcite . as mentioned earlier , accountability is meaningless if we can not check compliance .
table  [ table : principles ] presents the principles and their benefits at a glance .
we now evaluate iose with some prominent approaches from se .
we choose these either because ( 1 ) they are representative of broad classes of approaches for modeling sociotechnical systems ( i * , tropos , kaos ) , or ( 2 ) they give emphasis to interaction and protocols ( gaia and choreographies ) .      lacking a treatment of healthcare in i * and tropos approaches
, we study yu s treatment of meeting scheduling in i * @xcite , which is similar in spirit to the appointment scheduling protocol discussed earlier . despite its simplicity
, meeting scheduling provides sufficient subtlety to demonstrate various modeling approaches @xcite and is extensively used in the literature .
the main requirement in this scenario is to automate and make efficient some aspects of meeting scheduling so that the meeting initiator s burden is reduced .
figure  [ fig : sd - system - to - be ] shows the _ system to be _ for a meeting scheduling system in the i * notation .
the circles represent the actors in the system : meeting initiator ( mi ) , meeting participant ( mp ) , and meeting scheduler ( ms ) . the directed links between the actors represent _
dependencies_. for example , mi depends on mp for achieving the goal that _ the participant attend the meeting _ ( ) . in the i * terminology , figure  [ fig : sd - system - to - be ] is a _ strategic dependency _ ( sd )
diagram .    according to yu , in _ early requirements engineering _
, i * helps come up with an initial set of requirements .
specifically , i * helps identify the goals of the various stakeholders and their dependencies in achieving those goals .
a new system actor is introduced unto which some of these goals are _ delegated_. the system actor represents the machine to be designed to meet stakeholder goals .
this _ goal - modeling _
phase helps refine the system actor s goals and its dependencies with the other actors . in figure
[ fig : sd - system - to - be ] , the meeting scheduler ms is the system actor and is responsible for many tasks that mi was responsible for in the system as is ( not shown ) , such as obtaining availability information from participants and choosing a date that suits all participants .
= [ draw , rectangle , rounded corners=4pt , inner sep=2pt , text width=8ex , align = center ] = [ draw , ellipse , text width=6ex , align = center ]    = [ draw , rectangle , text width=8ex , align = center ]    = [ draw , circle , text width=6ex , align = center ]    = [ myarrow data=0.5 ] = [ font= ] ( as - is ) [ draw = none , row sep=0 mm , column sep=2mm , align = center ] ( empty - tl ) ; & [ 0 mm ] & ( attends ) attends + meeting ; & [ 4 mm ] ( empty - tr ) ; + & ( scheduled ) meeting scheduled ; & & ( empty - two - r ) ; + & ( empty - three - l ) ; & ( available ) available dates ; & + ( initiator ) meeting + initiator + ( mi ) ; & ( scheduler ) meeting + scheduler + ( ms ) ; & ( proposed ) proposed dates ; & ( participant ) meeting + participant + ( mp ) ; + & & ( agreed ) agreement ; + & ( range ) date range ; & ( subgoal ) attends + meeting ; + ( empty - bl ) ; & ( assured ) assured ; & & ( important ) important + participant + ( ip ) ; + ; ( important ) to ( participant ) ;    ( initiator ) .. controls ( empty - tl ) .. ( attends ) ; ( attends ) .. controls ( empty - tr ) .. ( participant ) ;    ( initiator ) to [ bend left ] ( scheduled.west ) ; ( scheduled ) to ( scheduler ) ;    ( initiator ) to [ bend right ] ( range ) ; ( range ) to ( scheduler ) ;    ( scheduler ) .. controls ( empty - three - l ) .. ( available.west ) ; ( available.east ) to [ bend left ] ( participant ) ;    ( scheduler ) to ( proposed ) ; ( proposed ) to ( participant ) ;    ( scheduler ) to ( agreed.west ) ; ( agreed.east ) to ( participant ) ;    ( initiator ) .. controls ( empty - bl ) .. ( assured ) ; ( assured ) to ( important ) ;    ( initiator.south ) to ( subgoal ) ; ( subgoal ) to ( important ) ;    tropos is an agent - oriented software engineering ( aose ) methodology that builds on the i * metamodel @xcite .
tropos follows i * s goal modeling phase with an architectural phase that maps the system actor to new actors that are interconnected through appropriate data and control dependencies .
the detailed design phase models each of these actors as one or more belief - desire - intention agents .
the implementation phase realizes the agents , thereby completely implementing the system actor .
both i * and tropos would create a system actor for an entire healthcare system .
this actor would capture ( a consistent subset of ) the goals of all stakeholders , thereby functioning as a logically centralized machine .
the comments below apply equally to i * and tropos .    * _ accountability modularity : _ violated .
there is no discrete principal behind the system actor and it is not meaningful to talk of its accountability . for example , ms , the system actor in figure  [ fig : sd - system - to - be ] is not accountable to the stakeholders . in general , dependencies in i * do not support accountability  just because an actor depends on another for a goal does not make the latter accountable for it . for example , figure  [ fig : sd - system - to - be ] shows that the mi depends on the mp for attending the meeting ; however it does not automatically follow ( without reasoning about communication and the resulting commitments , as in iose ) that the mp is accountable for showing up . * _ explicit social meaning : _ partially fulfilled .
the purpose behind the notion of dependencies in i * was to capture interactor relations in terms of high - level abstractions .
however , i * dependencies refer to actors mental states , and are not social , as further explained under encapsulation below . * _ solely social meaning : _ partially fulfilled .
dependencies are the only interactor abstraction . however ,
as we mentioned above , i * dependencies are not social abstractions . * _ separating social from technical : _ partially fulfilled .
i * treats social and technical actors alike with the same kinds of dependencies between any pair of actors .
for example , ms is a technical actor whereas mp and mi are stakeholders but ms s dependencies with mi and mp are of the same nature as those between mi and mp .
however , to its credit , in the early requirements modeling phase , all the actors are stakeholders and only in the later phases ( starting from late requirements modeling ) are technical actors introduced . *
_ no principal internals : _ violated .
an i * goal dependency between two actors @xmath1 and @xmath2 for some goal @xmath20 means that @xmath1 has a goal @xmath20 , and @xmath2 is _ able _ to achieve @xmath20 and in addition _ intends _ to deliver @xmath20 .
for example , as figure
[ fig : sd - system - to - be ] shows , mi depends on ms for its goal .
this dependency means that ( 1 ) mi has a goal to have the meeting ; ( 2 ) ms is able to schedule the meeting ; and ( 3 ) ms intends to schedule the meeting .
in other words , a goal dependency expresses a shared goal , indicating _ joint intentionality _
, among the actors .
( soft goal , task , and resource dependencies are interpreted analogously . )
thus the connection expressed between actors is rooted in their internals .
indeed , yu states this : `` the strategic dependency model aims to present a picture of agents by explicitly modeling only their external intentional relationships with each other .
the semantics of these external relationships , however , are characterized in terms of some _ presumed internal intentional features _ of the agent '' ( * ? ? ?
* , emphasis added ) .    in summary , the good points about i * and tropos are that they model stakeholders and stakeholder relations explicitly as actors and dependencies .
their shortcomings include the machine - orientation underlying the notion of system actor ; mentalist dependencies ; and violation of encapsulation .
that is , i * and tropos can help design a machine in a cooperative setting , where autonomy is not a consideration , but do not adequately address the engineering of a sociotechnical system .
dardenne et al.s kaos resembles tropos in its goal - orientation .
kaos first elicits stakeholders goals and represents them as and - or graphs .
next , it selects a particular variant of the graph as the basis for further engineering .
domain analysis reveals the possible sets of agents in the system to be along with their capabilities .
kaos s strength lies in the methodological details of deriving operational constraints from goals and assigning them to particular agents as responsibilities depending on their capabilities . for uniformity
, we consider examples from van lamsweerde et al.s study of the meeting scheduler .
the notion of _ agents _ in kaos is fundamentally different from that of principals in iose .
agents in kaos may be social ( human ) or technical , e.g. , devices and software programs .
further , an agent is considered a performer of actions , which are themselves defined in terms of input , output , precondition , and postcondition .
for example , van lamsweerde et al .
specify a agent that has the capability to perform the action , whose preconditions are that the meeting be requested but not scheduled and whose postconditions are ( 1 ) if the meeting is feasible , it is scheduled and ( 2 ) if it is not , the scheduling attempt fails .
other agents in van lamsweerde et al.s meeting scheduling system are and , which are analogously specified .    in kaos , a system specification captures adequately refined goals ( operational in nature ) and their assignment to agents with the requisite capabilities .
for example , the goal of notifying participants is assignable either to the or because they are both capable of notifying participants ; the goal of maintaining an up - to - date agenda that the could consult is the responsibility of every ; and so on .
the idea is that if the agents are appropriately specified and the goals are appropriately assigned , then overall system goals would be met .
kaos specifications capture neither communications among the agents nor explicit relationships among them .
instead kaos conceptualized agents as monitoring and setting the appropriate system - level ( meaning global ) variables and predicates .
kaos would model the healthcare system via multiple agents but assign the goals of each agent , thereby creating a conceptually centralized machine .
the contrast with iose principles is stark :    * _ accountability modularity : _ violated .
kaos s notion of composite system is exactly that of figure  [ fig : machine - environment ] : the two components are the automated system and the environment @xcite .
the users are considered part of the environment .
the automated system consists of software agents .
thus kaos supports the specification of a distributed machine ( for example , above , we discussed the kaos specification of agents for the meeting scheduler system ) .
the automated system represents the realization of the stakeholder requirements ; hence it is meaningless to talk its accountability to anyone .
we note here that the notion of responsibility in kaos in not a social one : a responsibility is simply an operational constraint that is assigned ( and therefore , designed ) into an agent . * _ explicit social meaning : _ violated .
kaos does not model communication nor employ any communication - related social abstractions .
further , unlike tropos , it does not have abstractions to capture any interagent relations .
all interaction between agents is captured only indirectly  through the setting of the appropriate variables and predicates in the environment . * _ solely social meaning : _ violated . since kaos does not support social meaning . * _ separating social from technical : _ violated .
kaos models a sociotechnical system in a purely technical way .
neither stakeholders nor principals are accommodated in the system model .
in fact , kaos does not even model the goals as being of particular stakeholders : there is just one goal tree , which is progressively refined until the leafs can be assigned to agents .
the names of the agents in the meeting scheduling system ( , and so on ) may suggest that kaos accommodates principals .
however , that would be misleading : agent specifications together with goal assignments are essentially abstract programs .
the entire automated system is a collection of programs interacting via variables . * _ no principal internals : _ violated .
the system is ultimately a collection of agents whose assigned responsibilities determine their implementations . since the system s correct functioning depends on the goals assigned to its member agents , kaos breaks encapsulation .    like tropos
, kaos applies in designing a technical system in a cooperative setting , but its machine - orientation precludes engineering an open sociotechnical system .
zambonelli et al.s gaia is one of the earliest aose methodologies .
later aose methodologies bear many conceptual similarities with gaia .
hence , it deserves an in - depth discussion .
gaia takes an organization - based approach in which agents may adopt roles .
zambonelli et al .
consider a conference management system in which agents may adopt the appropriate roles ( such as reviewer , pc member , author , and so on ) .
a role defines the permissions and responsibilities of a prospective agent .
permissions describe what an agent could do with resources in the environment .
responsibilities are algebraic expressions over the protocols and internal activities that an agent must perform
. for reviewer , the permissions are and and the responsibilities are first ( a protocol ) , second ( an internal activity ) , and third ( a protocol ) . below we discuss gaia with respect to the iose principles .
* _ accountability modularity : _ violated . in gaia ,
technical components such as mail clients and active databases are agents .
it is meaningless to talk about their accountability .
even if the agents represented only stakeholders , gaia says nothing about to whom they are accountable .
for example , if a reviewer may not send a review form , would it be responsible to the overseeing pc member ?
gaia says nothing about that .
+ zambonelli et al .
conceptualize the multiagent system as an organization that `` can exploit , control or consume when it is working towards the achievement of the organizational goal '' ( p.  328 ) .
further , gaia specifies _ organizational rules _ `` that the organization should respect and enforce in its global behavior '' ( p.  335 ) .
both these points seem to hint toward a conceptually central entity in the system .
although gaia never explicitly mentions it , perhaps all agents that adopt roles are accountable only to this central entity .
however , this resembles a conceptually centralized perspective and makes the system conception in gaia similar to the one in figure  [ fig : machine ] . * _ explicit social meaning : _ partially fulfilled .
whereas gaia supports specifying interaction among roles , it does not specify the meaning of the communications itself .
gaia has the notions of permissions and responsibilities at the role level .
the intent behind these notions seems to have been to capture social aspects of organizations ; however , gaia falters in important details . as stated above , permissions and responsibilities in gaia
are not interagent relationships .
for example , the reviewer has the permissions and . but this seems to assume a computational intermediary ( left unspecified in gaia ) with resources ( the papers ) where these activities must be performed .
( in iose , would be modeled as a communication from the reviewer to the program chair or the overseeing pc member and its body would contain the updated review . )
responsibilities specify what an agent adopting the role ought to do but again this seems to assume an unspecified entity to whom the agent would be responsible . * _ solely social meaning : _ violated . as we noted above ,
gaia does not have any true social abstractions . * _ separating social from technical : _ partially fulfilled .
gaia aspires to social - level modeling by modeling systems as organizations and having agents adopt roles in organizations .
gaia , to its credit , distinguishes between open systems and closed systems .
it explicitly mentions that agents could represent different stakeholders .
however , unlike a principal in iose , an agent in gaia is anything that has its own thread of control .
specifically , even in open systems , `` active '' components such as active databases , are modeled as agents . * _ no principal internals : _ violated .
gaia makes internal agent behavior ( e.g. , ) explicit by placing activities in role specifications , thereby exposing an agent s internal decision - making .
( would not appear in an iose protocol because it does not involve communication
it is an internal activity . )    in summary , gaia aspires to modeling open systems via roles and protocols , but falters in important details .
although it is not explicitly machine - oriented , it betrays a conceptually centralized mindset . as such , it is not adequate for the modeling of open sociotechnical systems .
a choreography specifies the schemas of the messages exchanged as well as constraints on their ordering and occurrence .
a choreography is conceptually decentralized and involves roles that principals may potentially adopt .
interestingly , choreographies fit in the paradigm of figure  [ fig : old ] .
principals adopting roles in a choreography would potentially maintain their own ledgers and interact via a digital messaging system that carries their messages to each other .
however , there is no computational support for the social state : choreographies do not specify the social meanings of messages and as a result do not capture the social expectations interacting principals may have of each other .
choreography description languages , e.g. , ws - cdl @xcite , support specifying the internal activities of principals in the choreography itself .
for instance , the ws - cdl notion of _ workunits _ may be used to specify conditional actions by a principal . likewise , mendling and hafner use workunits to specify the internal compliance checks that a tax adviser would make in handling a client s annual statement ( p.  532 ) , thereby violating encapsulation .
* _ accountability modularity : _ partially fulfilled .
choreographies support compliance at the technical level : principals must send messages in the prescribed order , otherwise they are not compliant with the choreography
. however , lacking representation of social meaning and social state , a violation of a choreography does not necessarily amount to a violation at the social level . * _ explicit social meaning : _ violated .
lack a representation of social meaning . *
_ solely social meaning : _ violated .
follows from the lack of a representation of social meaning . * _ separating social from technical : _ fulfilled .
choreographies specify interactions with reference to roles that principals may adopt . * _ no principal internals : _ partially fulfilled . in principle
, choreographies seek to specify interactions ; however , in practice , they also specify the internal activities of principals .
choreographies seek to model interactions ; however , they do so in terms of low - level control and data flow abstractions and often specify aspects of principals internal behavior .
therefore , they also do not fare well with respect to the iose principles .
table  [ table : principles - evaluation ] contrasts traditional approaches with commitment protocols , explained in section  [ sec : principles - iose ] as an exemplar of iose .
i * , tropos , and kaos are all machine - oriented since their primary specification artifact is that of a machine ( the system actor in i * and tropos and a collection of agents in kaos ) that would meet stakeholder requirements .
nonetheless , i * and tropos perform better than kaos in our evaluation because unlike kaos , they model stakeholders and their relations explicitly .
in the foregoing , we have extensively discussed the literature most pertinent to our claims . here , we discuss other relevant literature .    commitments .
commitments are recognized in the literature as a key social abstraction .
singh introduced social commitments as a way of formalizing agent communication that was suited to open systems .
fornara and colombetti gave an operational semantics for commitments .
yolum and singh specified commitment protocols in the event calculus .
newer work has tended more toward se themes : methodologies for composing commitment protocols @xcite , patterns @xcite , the relationship of commitments with the notion of goals in tropos @xcite , and monitoring requirements via commitments @xcite .
young and antn apply commitments to identify software requirements from regulatory policies and paja et al . to extract security requirements for organizations .
baldoni et al .
present commitment protocols that support temporal properties .
the value we add to this body of work is making explicit connections between the ontology and principles implicit in commitment - based approaches with those implicit in traditional se .
iose , as a new paradigm for the sociotechnical systems , provides a natural home for commitments .
agent - oriented software engineering despite the apparent similarity between the notion of agents and principals and talk of interaction in many aose methodologies , they ( as exemplified by gaia and tropos ) violate key iose principles . some aose approaches are logically centralized , e.g. , geared toward efficient problem - solving .
gaia and other aose methodologies acknowledge the distinction between open and closed systems and emphasize interactions .
they correctly classify problem solving systems that distribute a problem across agents as closed .
however , aose methodologies betray , if not centralized mindsets , at least considerable conceptual difficulties .
vsquez - salceda et al .
model the objectives of social systems as goals and the systems as controllers ( p.  338 ) : `` facilitation roles are usually provided by agents controlled by the society , and follow a trivial contract . ''
but in a sociotechnical system , there is no unitary multiagent system or society that controls resources . and an organization has no goals that overarch the goals of other participants  that is
, an organization would be one of many participants in a sociotechnical system .
van riemsdijk et al .
too are motivated by the modeling of open systems but conceptualize a multiagent system as having collective goals .
wagner s agent - object - relationship ( aor ) ontology proposes two kinds of models to support the design of a multiagent system : _ external _ ( observer s perspective , including interaction models ) and _ internal _ ( agent s perspective ) .
newer work by guizzardi et al . is based on the aor ontology .
wagner s internal - external distinction aligns well with iose .
unfortunately , aor subverts the internal - external distinction by including in external models aspects of the internal organization of agents , such as their beliefs ( in _ agent diagrams _ ) as well as reactive rules that specify how an agent would respond to events .
singh introduced social commitment as a concept distinct from the mentalist concept of _ internal commitment _ @xcite .
aor , tropos , and i * employ internal commitments .
serrano and leite map i * concepts to agent programming concepts such as beliefs , desires , and intentions .
they map dependencies between two agents to the joint desires of those agents . using their methodology
, one specifies the internals of one or more agents .
thus even though serrano and leite do nt involve an explicit system actor , the approach is conceptually centralized .
how can we reconcile the facts that many aose methodologies are conceptually centralized yet model interactions ?
aose methodologies yield physically distributed systems of agents that pursue centrally assigned goals .
interactions in aose are focused on the technical means to achieve such goals whereas interactions in iose have social standing .
information systems modeling mccarthy proposed rea as a generalized model for accounting that is based on _ resources _ , _ events _ , and _
agents _ and relations among them .
rea is finding applications in services and information systems modeling , e.g. , @xcite .
rea seeks to capture the fundamental economic model underlying accounting .
our endeavor is analogous : to develop a general model of sociotechnical systems , based on social abstractions .
the key distinction between iose and rea is that rea models ultimately represent an organization s internal perspective , not its interactions with others .
this is evident from rea s inside - outside distinction .
one of rea s _ accountability _ relations identifies the responsible agent for an event _ inside _ an organization ; another is between an outside agent and an event .
iose commitments are more general : each commitment identifies the accountable party and the party to whom it is accountable for what .
the second distinction stems from the _ duality _ of events and the corresponding _ reciprocity _ of commitments  reflecting the roots of rea in accounting . duality in rea relates two events that together characterize the give - and - take of an economic exchange ( e.g. , and ) .
these events _ execute _
( i.e. , fulfill ) the corresponding reciprocal commitments .
iose does not give any special place to either duality or reciprocity .
no iose commitment is necessarily reciprocal : if @xmath1 is committed to @xmath2 , there is no requirement that @xmath2 be committed to @xmath1 ( though it is allowed ) .
gordijn and akkermans propose the @xmath21-value ontology and associated methodology in order to specify and analyze so - called business models to evaluate their profitability for all stakeholders involved .
a business model represents stakeholders as actors ( e.g. , customer ) .
other important concepts are _ value objects _ ( e.g , online articles ) , and _ value exchanges _ among actors ( e.g. , with an article provider for articles and their payment ) .
commitment protocols could be used to capture the notion of value exchange among actors ; further commitment protocols could be analyzed for feasibility @xcite . however , unlike commitment protocols and in violation of iose principles , @xmath21-value models also depict the internal flow of values in petri net - like notation .    human - computer interaction ( hci ) following developments in hci , the term `` social '' is often associated in re with the interplay between social factors and the design of technical artifacts ( as in the _ design of work _
, e.g. , see @xcite ) , especially as concerns user interface and experience ( e.g. , see @xcite ) .
the iose treatment of `` social '' is more general and includes not just people but entities such as enterprises and organizations that may be conceptualized as social actors  which enables iose to tackle sociotechnical systems as we define them .
compliance compliance with service - level agreements , regulations , and business contracts is gaining interest in software engineering .
organizations are increasingly concerned with the question of compliance with regulatory frameworks such as hipaa @xcite and sarbanes - oxley .
the challenges here are threefold : one , how to model regulations ; two , how to determine the compliance of a principal s behavior with regulations ; and , three , how to design a principal s information systems such that it is ( likely to be ) compliant with the regulations .
siena et al .
develop a tropos - inspired modeling language to capture and reason about such regulations .
iose can potentially support a more flexible notion of compliance geared toward open systems .
although high - level concepts such as obligations , permissions , and so on are often employed in software engineering , they are used to capture behavioral constraints abstractly but are not grounded in communication as commitments are .
a more detailed discussion is out of the scope of this paper but interested readers are referred to @xcite for an in - depth discussion .
our work began from the recognition that open sociotechnical systems are conceptually decentralized and their principals are autonomous social entities . specifying a sociotechnical
system amounts to specifying a protocol , i.e. , a specification of the interactions among its potential participants .
we showed that existing approaches take a fundamentally centralized view of sociotechnical systems design : they are geared toward the specification of a machine , not a protocol .
we presented iose as a new approach for the engineering of sociotechnical systems .
iose is driven by key technical demands : autonomy , accountability , and loose coupling . to illustrate iose , we introduced protocols in which the meanings of the messages are specified in terms of commitments as a natural way to address these technical demands .
we formulated the iose principles inspired by , but distinct from , the traditional se principles .
we undertook a detailed analysis of some leading relevant se approaches to show which iose principles they violate .
traditional se falls short not because the abstractions it employs are low level , but because they deemphasize interaction . to support this claim ,
we consider well - known requirements modeling approaches , which emphasize high - level abstractions such as goals and dependencies @xcite but do not accord first - class status to interactions .    even in the simple appointment scheduling setting ,
the benefits of iose are obvious : what was previously seen as the problem of specifying a meeting scheduler , under iose turns into two independent problems of ( 1 ) specifying the meeting scheduling protocol , and ( 2 ) specifying principals to participate in the protocol .
this reflects parnas conception of modularity as the _ division of labor_.    our evaluation of the traditional approaches is not a blanket criticism but rather a critical examination that highlights the differences in their assumptions from the principles of iose .
further , our evaluation was limited to the system models or specifications that existing approaches advocate .
we did not , for instance , dwell upon the modeling of functional versus nonfunctional requirements or the elicitation of requirements from stakeholders , areas in which current sociotechnical systems approaches ( including i * , tropos , and kaos ) have made substantial progress .
although we carefully differentiate iose from traditional se , the two complement each other .
iose deals with systems ( viewed as protocols ) whereas traditional re deals with components or principals behaviors ( viewed as machines ) .
the former is typified by commitments and other social constructs ; the latter by goals and other mental constructs .
recent works @xcite have begun to relate these views from the standpoint of building agents who can function effectively in sociotechnical systems characterized by commitments .
we have recently @xcite , sought to apply tropos - like models towards the specification of sociotechnical systems .
these works replace intentional dependencies with commitments and do not consider a system actor .
further , each actor is understood as a role , i.e. , inert and lacking any goals .
goals are applied in the modeling the principals who may potentially adopt roles in the sociotechnical system .
we defer the task of systematically laying out the methodological elements of iose , as they overlay the main concepts and principles we introduced above .
we expect to go beyond methodologies for specifying and composing protocols , e.g. , @xcite , by incorporating the key re considerations of stakeholders and requirements .
the nature of requirements for protocols appears quite different from requirements for machines .
for example , a requirement such as `` a meeting is scheduled within three hours of the request '' makes sense for a machine but not a protocol  though it could be negotiated between the principals playing the mi and mp roles .
a requirement that `` a principal can observe whether another principal is complying with some commitment '' makes sense for a protocol but less so for a machine .
the bases from which to engineer protocols is a timely and pertinent direction of research .
we imagine that existing re methodologies would provide a useful starting point for investigations into a methodology for iose .
amit chopra was supported by a marie curie trentino cofund grant and the erc advanced grant 267856 .
we thank fabiano dalpiaz , paolo giorgini , michael huhns , michael jackson , john mylopoulos , and erik simmons for helpful discussions .            ,
dalpiaz , f. , giorgini , p. , and mylopoulos , j. 2010a .
modeling and reasoning about service - oriented applications via goals and commitments . in _ proceedings of the 22nd international conference on advanced information systems engineering ( caise)_. lncs
series , vol .
springer , 113128 .    ,
dalpiaz , f. , giorgini , p. , and mylopoulos , j. 2010b .
reasoning about agents and protocols via goals and commitments . in _ proceedings of the ninth international conference on autonomous agents and multiagent systems ( aamas)_. 457464 .              ,
narendra , n.  c. , and singh , m.  p. 2008 .
checking correctness of business contracts via commitments . in _ proceedings of the 7th international conference on autonomous agents and multiagent systems ( aamas)_. ifaamas , estoril , portugal , 787794 .
\2002 . operational specification of a commitment - based agent communication language . in _ proceedings of the 1st international joint conference on autonomous agents and multiagent systems ( aamas)_. acm press , 535542 .
requirements engineering as the reconciliation of technical and social issues . in _ requirements
engineering : social and technical issues _ , m.  jirotka and j.  goguen , eds . academic press , 165200 .          ,
baldoni , m. , baroglio , c. , chopra , a.  k. , patti , v. , , and singh , m.  p. 2011 .
commitment with regulations : reasoning about safety and control in regula . in _ proceedings of the 10th international conference on autonomous agents and multiagent systems ( aamas)_. 467474 .            ,
dalpiaz , f. , poggianella , m. , roberti , p. , and giorgini , p. 2012 . : using commitments to specify socio - technical security requirements . in _ proceedings of the er 2012 workshops_. lncs
series , vol .
springer , 396399 .
development of agent - driven systems : from i * architectural models to intentional agents code . in _ proceedings of the 5th international i * workshop_. ceur workshop proceedings series , vol . 766 .
ceur-ws.org , 5560 .    ,
armellin , g. , mameli , g. , mylopoulos , j. , perini , a. , and susi , a. 2010 . establishing regulatory compliance for information system requirements :
an experience report from the health care domain . in _ proceedings of the 29th international conference on conceptual modeling_. lncs
series , vol .
springer , 90103 .
commitments in multiagent systems : some history , some confusions , some controversies , some prospects . in _ the goals of cognition : essays in honor of cristiano castelfranchi _ , f.  paglieri , l.  tummolini , r.  falcone , and m.  miceli , eds .
college publications , london , chapter  31 , 591616 . in press ; available at http://www.csc.ncsu.edu/faculty/mpsingh/papers .      , lock , r. , storer , t. , and dobson , j. 2009 .
deriving information requirements from responsibility models . in _ proceedings of the 21st international conference on advanced information systems engineering_. amsterdam , 515529 .
\2009 . enhancing tropos with commitments : a business metamodel and methodology . in _ conceptual modeling : foundations and applications _
, a.  borgida , v.  chaudhri , p.  giorgini , and e.  yu , eds .
number 5600 in lncs .
springer , 417435 .    , yorke - smith , n. , and singh , m.  p. 2012 .
relating goal and commitment semantics . in _ proceedings of the 9th international workshop on programming multiagent systems ( promas 2011)_. lncs series , vol
springer , taipei , 2237 .        ,
darimont , r. , and massonet , p. 1995 .
elaboration of requirements for a meeting scheduler : problems and lessons learnt . in _ proceedings of the second ieee international symposium on requirements engineering_. 194203 .    ,
hindriks , k. , and jonker , c. 2009 . programming organization - aware agents : a research agenda . in _ engineering societies in the agents
world x _ , h.  aldewereld , v.  dignum , and g.  picard , eds .
lncs series , vol .
springer , 98112 .        , johannesson , p. , andersson , b. , arachchige , j.  j. , and bergholtz , m. 2011 .
management services  a framework for design . in _ proceedings of the 23rd international conference on advanced information systems engineering ( caise)_. lncs
series , vol . 6741 .
springer , 582596 .
flexible protocol specification and execution : applying event calculus planning using commitments . in _ proceedings of the 1st international joint conference on autonomous agents and multiagent systems_. acm press , 527534 .