=Paper=
{{Paper
|id=Vol-2641/paper_10
|storemode=property
|title=Social Dependence Relationships in
Requirements Engineering
|pdfUrl=https://ceur-ws.org/Vol-2641/paper_10.pdf
|volume=Vol-2641
|authors=John Mylopoulos,Daniel Amyot,Luigi Logrippo,Alireza Parvizimosaed,Sepehr Sharifi
|dblpUrl=https://dblp.org/rec/conf/istar/MylopoulosALPS20
}}
==Social Dependence Relationships in
Requirements Engineering==
https://ceur-ws.org/Vol-2641/paper_10.pdf
Social Dependence Relationships in
Requirements Engineering?
John Mylopoulos1 , Daniel Amyot1 , Luigi Logrippo1,2 , Alireza Parvizimosaed1 ,
and Sepehr Sharifi1
1
School of EECS, University of Ottawa, Ottawa, Canada
{jmylopou, damyot, logrippo, aparv007, sshar190}@uottawa.ca
2
Université du Québec en Outaouais, Gatineau, Canada
Abstract. i* is a requirements modelling language that is founded on
social concepts (actors, social dependencies). Azzurra is a business pro-
cess specification language that uses roles and commitments as primi-
tives. Symboleo is a smart contract specification language grounded in
legal concepts (roles, parties, obligations, powers). We compare and con-
trast the social dependence relationships used by the three languages.
Keywords: Requirements Engineering · Social Dependency · i* model.
1 Introduction
One of the key elements of i* [3] is that of social dependency3 that holds be-
tween two actors, a depender who depends on a dependee to satisfy a dependum
(goal, task, resource, softgoal). This is a very powerful concept that constitutes
the foundation for social modelling and has spawned interesting dependence re-
lationships for software, business processes, and legal contracts. The purpose of
this paper is to discuss the ontological nature and contrast three types of social
dependence relationships: social dependencies (i* ), commitments (Azzurra) [2],
as well as obligations and powers (Symboleo) [4]. These relationships were devel-
oped over three decades and involved many collaborators beyond the authors.
Given that the languages target different domains, different examples are
used for illustration. Note also that a full comparison of these languages is beyond
the scope of this paper.
2 Social Dependencies (i* )
In an i* social dependency (Fig. 1), the depender wants something and the de-
pendee is able and willing to deliver it. However, the force of the dependence can
?
Partially funded by an NSERC Strategic Partnership Grant titled “Middleware
Framework and Programming Infrastructure for IoT Services” and by SSHRC’s
Partnership Grant “Autonomy Through Cyberjustice Technologies”
3
We use the term ‘social dependence relationship’ synonymously with ‘social depen-
dency’.
Copyright © 2020 for this paper by its authors. Use permitted under 55
Creative Commons License Attribution 4.0 International (CC BY 4.0).
Fig. 1: Example of social dependence relationship in i*
vary from weak to strong on either side of the dependum. Consider a customer’s
dependence on a shop to find her favourite hair shampoo: it is weak because
there are probably other stores that sell it as well, and other shampoos are also
comparable. Contrast this with one’s dependence on a renowned surgeon for
a rare medical operation. This one is strong, because there are no substitute
dependees. The force of the dependence on the dependee’s side is even more
important, as she is responsible for delivering on the dependence. That force
is defined along two dimensions: ability to deliver on the dependum and degree
of commitment to deliver. The dependence on the renowned surgeon is strong
on ability and medium on commitment, as surgeons will postpone operations in
case of an emergency.
Now, consider a beggar who depends on passersby to fulfill her goal of having
some money. This is a social dependence too and it is weak on both sides: the
beggar can switch to another kind of dependence to get some money, e.g, work,
while the passersby have not even agreed explicitly to the beggar to deliver on
the dependum, they are just willing to do it, occasionally. Here, the dependence
is established statistically: some passersby give money, and sooner or later this
establishes a dependency for the beggar.
i* does recognize the importance of the force of a dependence by allowing
three possible levels of force: critical, committed, and open [3]. But, as discussed
in the sequel, it turns out that in other areas of research, people have opted for
defining specializations of social dependence relationships where the strength of
dependence is built into their semantics. Commitments, obligations, and powers
are three such relationships.
i* was developed at the University of Toronto in the early ‘90s as part of
Eric Yu’s PhD thesis, with collaborators Lawrence Chung, Brian Nixon, and
John Mylopoulos. It further led to the development of many other languages
and dialects, including the Goal-oriented Requirement Language, part of the
User Requirements Notation standard, with collaborators documented in [1].
3 Commitments (Azzurra)
Originating in the area of multi-agent systems [5], commitments capture a social
dependence where there is an explicit speech act executed “Agent A: I want X
- Agent B: I commit to fulfill X”. This kind of dependency has substantially
more force than the beggar’s dependence on passersby. It means that the de-
pendee intends to deliver, provided some conditions hold. So, commitments are
56
social dependencies that always arise from intentions, rather than mere prac-
tice, and are established through verbal acts. More formally, commitments are
4-tuples C(debtor, creditor, antecedent, consequent), where the creditor
is the depender, i.e., the beneficiary of the commitment being fulfilled, while the
debtor is the dependee. Moreover, the commitment is fulfilled when the conse-
quent becomes true, provided the antecedent is true. Moreover, commitments
go through states, such as ‘created’, ‘active’, ‘suspended’, ‘success’, and ‘failure’.
Allowable state transitions are defined by a state diagram. Note that commit-
ments constitute specializations of social dependencies, with better fleshed out
semantics, proposed for use in multi-agent systems. They also come with a pre-
cise level of force for the debtor who intends to fulfill what she committed to,
while the creditor has the right to expect that the commitment will be fulfilled.
The passersby mentioned earlier have no commitment towards the beggar and,
in turn, she has no right to expect anything from them.
Azzurra is a conceptual modelling language for business processes. Its main
thesis is that such processes, being social artifacts, need to be defined in social
terms, rather than system-oriented ones (e.g., Petri nets or BPMN). Accordingly,
business processes (aka ‘protocols’) are defined in terms of roles and commit-
ments, with constraints attached. Azzurra models can be seen as requirements
specifications for business processes, as they describe what a business process is
supposed to achieve without getting into the details of how to achieve it.
Figure 2 (adapted from [2]) presents an Azzurra protocol for fracture treat-
ment. The protocol includes as parameters a hospital number that serves as key
for treatment instances, a patient, and a specialist. It also includes role param-
eters, such as a radiologist and a surgeon.
There are nine commitments for this protocol, each using a
format. The first, C1 , is triggered when the protocol is instanti-
ated, has as roles the specialist (debtor) and the patient (creditor), is uncondi-
tional (antecedent= true), and is fulfilled when the patient is i) examined, then
ii) diagnosed, and then iii) dis-hospitalized. The second commitment, C2 , is trig-
gered if there is no need for X-rays and is fulfilled when a sling is made for the
patient. Protocol refinements constrain the agents that participate in a protocol
instance. For example, agents may be constrained on how many concurrent com-
mitments they have for a given role, such as a surgeon for treatment protocol
instances. Finally, a knowledge base defines some domain axioms, which can be
used to reason about propositions used as triggers or as elements of commitment
antecedents and consequents.
Azzurra supports two types of reasoning. ENACTPROTOCOL determines how an
event updates the state of a protocol instance and of the commitment instances
therein. CHECKCOMPLIANCE checks whether an occurred event violates the spec-
ification of a protocol instance. This corresponds to identifying commitments
that are not created/fulfilled, unexpected commitment operations, and protocol
constraint violations.
In summary, commitments specialize and improve the formalization of social
dependence relationships. They also come with a richer language than i* for
57
Fig. 2: An Azzurra protocol for fracture treatment (from [2])
modeling business processes in an outcome-oriented way. Azzurra was developed
at the University of Trento between 2012 and 2016 and only managed a few
publications including a best paper, awarded at RCIS 2015. The collaborators
for that project included Fabiano Dalpiaz, Evellin Cardozo, Giulia Canobbio,
Paolo Giorgini, and John Mylopoulos.
4 Obligations and Powers (Symboleo)
Obligations are commitments with legal force. The legal force is defined through
powers that a creditor has towards the debtor of an obligation to cancel or
suspend an obligation or another power, or to initiate new obligations or powers.
Obligations constitute a specialization of the concept of commitment in that they
can be created, cancelled, etc. by someone who has the power to do so. In turn,
powers constitute specializations of obligations in that they can include in their
consequent the creation, cancellation, etc. of other powers or obligations.
Obligations and powers can be found in legal contracts. Legal contracts can
be thought as processes too, but they are legal rather than business ones, in
that they describe the space of allowable executions that comply with terms and
conditions of a contract. The presence of powers in legal contracts make them a
much more malleable concept than that of a business process in that they can
be reshaped through powers with the introduction/cancellation of obligations
while a contract is being executed (i.e., “performed” in Law).
Symboleo is a formal specification language for legal contracts, intended to
formalize requirements for smart contracts. These are software systems running
58
Table 1: Abbreviated Symboleo specification for a goods sale contract
Domain salesD
Goods isA Asset with goodsID: Integer;
...
Delivered isA Event with delAddress: String, delDueDate: Date;
endDomain
Contract salesC seller: Seller, buyer: Buyer, ID: Integer, amnt: Integer, curr: Currency, de-
lAdd, delDd: String
Declarations
/∗ Values of parameters are passed on to the variables defined in the domain model. ∗/
goods : Goods with goodsID := ID;
...
delivered : Delivered with delAddress := delAdd, delDueDate := delDd;
Preconditions
isOwner(seller, goods) AND NOT isOwner(buyer, goods);
Postconditions
isOwner(buyer, goods) AND NOT isOwner(seller, goods);
Obligations
O1 : O(Seller, Buyer, true, happensBefore(delivered, delivered.delDueD));
O2 : O(Buyer, Seller, true, happensBefore(paid, paid.payDueD));
Powers
P1 : violates(O2 , ) → P(Seller, Buyer, true, terminates(salesC));
SurvivingObl
/∗ Some obligations may remain active, e.g., confidentiality obligations. ∗/
Constraints
not(isEqual(buyer, seller));
endContract
on a blockchain platform (or involving a regular database) that monitor and
control the execution of a legal contract. Symboleo is founded on an ontology
for contracts that is centered around the notions of obligation and power, and
includes role and party (the actors playing roles in a contract), asset, as well as
situation and event. Situations occur over time, e.g., the situation of commuting
to work. Events, on the other hand, happen instantaneously, e.g., arrivedAtWork.
The language adopts many elements from Azzurra. Obligations and pow-
ers use the same format as commitments. Their antecedents, consequents, and
triggers are expressed as events happening in a certain order and satisfying con-
straints. For example, for a sale contract, the consequent of a delivery obligation
may be “Sale item delivered to delivery address by delivery date”.
Table 1 presents a Symboleo specification for a contract (adapted from [4]).
As shown, a Symboleo specification begins with the description of concepts in
the domain. These are defined as classes that specialize concepts in the Symboleo
ontology. For example, Goods specializes Asset and has an additional attribute
goodsID. Instances of this class include sale items involved in a sale transaction.
The domain model for a contract is followed by declarations of variables that
take as values instances of domain classes. Pre/post-conditions have the same
semantics as in program specifications.
The core of a contract specification are its obligations and powers. In our
example there are two obligations: the seller must deliver the sale item to the
delivery address by the delivery date (O1 ), while the buyer must pay on time
59
the sale amount (O2 ). The contract also includes one power: if the buyer violates
the payment obligation, the seller has the power to terminate the contract (P1 ).
Note that the creditor of a power may choose to not exercise it.
Legal contracts are complex constructs with many features that go well be-
yond those of business processes. For instance, some obligations may apply after
the successful termination of a contract (and are accordingly called surviving
obligations), e.g., a confidentiality obligation for a sale transaction may apply
6 months after a contract terminates. Contracts may spawn subcontracts that
may be established while a contract is executing. For example, when a developer
undertakes a large project in the construction industry, she may not have lined
up all the subcontractors and their respective subcontracts.
Symboleo specifications can be validated to ensure that they are consistent
with the expectations of the contracting parties by a tool (https://doi.org/10.
5281/zenodo.3903954) that enacts scenarios and determines the contract final
state. For example, for the scenario “Seller delivers on time, buyer does not pay
on time, seller exercises power to terminate”, the tool determines that the final
state of the contract is ‘cancelled’. The scenarios for validation are provided by
contracting parties, along with their anticipated final state of the contract when
each scenario is enacted.
The Symboleo project started in January 2018 and is ongoing at the Univer-
sity of Ottawa with the co-authors of this paper as main contributors.
5 Conclusions
The concept of social dependence relationships in RE was pioneered by i*. This
provided a solid conceptual base that is being proven to be of lasting value
for developments in other application domains. With changes in syntax and
semantics, it led to formalizing the concept of commitment in business processes
in Azzurra. Then came the introduction of contractual obligations and powers
in Symboleo, which leads to the possibility of monitoring legal compliance in
contracts, possibly with blockchain support. We expect the social dependence
concept to influence other languages in the future.
References
1. Amyot, D., Mussbacher, G.: User Requirements Notation: the first ten years, the
next ten years. Journal of Software (JSW) 6(5), 747–768 (2011)
2. Dalpiaz, F., Cardoso, E., Canobbio, G., Giorgini, P., Mylopoulos, J.: Social specifi-
cations of business processes with Azzurra. In: 9th RCIS. pp. 7–18. IEEE (2015)
3. Eric, S., Giorgini, P., Maiden, N., Mylopoulos, J.: Social modeling for requirements
engineering. MIT Press (2011)
4. Sharifi, S., Parvizimosaed, A., Amyot, D., Logrippo, L., Mylopoulos, J.: Symboleo:
A specification language for smart contracts. In: 28th IEEE International Require-
ments Engineering Conference (RE’20). IEEE CS (2020), (to appear)
5. Singh, M.P.: An ontology for commitments in multiagent systems. Artificial intelli-
gence and law 7(1), 97–113 (1999)
60