Software evolution is the main research focus of the Tropos group at University of Trento (UniTN): how do we build systems that are aware of their requirements, and are able to dynamically reconfigure themselves in response to changes in context (the environment within which they operate) and requirements. The purpose of this report is to offer an overview of ongoing work at UniTN. In particular, the report presents ideas and results of four lines of research: contextual requirements modeling and reasoning, commitments and goal models, developing self-reconfigurable systems, and requirements awareness.
At the University of Trento (UniTN), research on Tropos is conducted within the Software Engineering and Formal Methods research program1. Currently, our main research challenge is facilitating software evolution so that systems may be able to evolve in response to changes in their operational environment and, more pertinently, in their requirements themselves. We are addressing this challenge by formalizing high-level concepts, and developing tools, techniques, and methodologies around these concepts. Our approach is to support evolution via design-time models that are made available at runtime. These models capture stakeholder intentions and commitments, social interactions, business processes, and organizational goals.
Evolution can be automatic (self-adaptation), or manual, or something in between. When evolution is automatic, design-time models determine what is to be monitored, what are the possible ways to adapt the behavior of the system when it deviates from its intended purposes, and how to evolve the system at runtime. When evolution is manual, these models are used as support for human activities. They offer a comprehensive view of the requirements and traceability links between elements of these models and the software code.
Our activities in the area of software evolution may be broadly divided into the following topics: contextual requirements modeling and reasoning, commitments and goal models, architectures for self-reconfigurable systems, and requirements awareness. The following elaborates on each.
Modeling and reasoning about contextual requirements. Advances in computing,
sensors, and communication technology have given rise to new computing paradigms
such as ambient, ubiquitous and pervasive computing. These paradigms weave
computing systems with human living environments to transparently meet human
needs. Context, a core element of these paradigms, can be defined as the reification of
the environment, and includes whatever provides a surrounding within which the
system operates [
In our research, we are interested in modeling and reasoning techniques for
developing software systems expected to operate in varying contexts. We extend the
Tropos goal modeling framework [
Social commitments and goal models. Requirements modeling for open settings
such as for service-oriented and sociotechnical systems pose new challenges due to
the autonomy and heterogeneity of the participants, that is, agents. Such settings are
also highly dynamic—agents may not even know each others’ identities before
runtime [
The i* approach was influential in emphasizing the social nature of requirements fulfillment—agents often depend on others to achieve their goals. An i* dependency involves one actor wanting something, and another being able and committed to delivering that something. However, i* does not does not achieve a clean separation between an agent’s internals and its social relationships with others. For example, the formalization of dependencies refers to the ability of the dependee, that is, its internal routines. As a result, i* has limited applications in open settings.
Our recent work on modeling agents and social relations among them replaces
dependencies with interaction protocols and social commitments [
An agent’s beliefs about another’s ability or intentions with respect to a certain goal may be important in arriving at certain decisions. However, it is also important to systematically understand and separate the internal from the external—this enables us to build agent reasoning in a modular fashion. For example, an agent may first determine if a protocol is suitable for its goals, and then select with whom to interact within that protocol based on its internal model of others.
Social commitments are more expressive than dependencies in i*. Social
commitments are conditional, thus enabling capturing reciprocity among agents—that
if one agent brings about some condition, then the other bring about another
condition. Moreover, social commitments also refer to the contextual setting—these
are often important in contractual settings. Formal reasoning for social commitments
is also well-developed [
Architectures for self-reconfigurable sociotechnical systems. A sociotechnical
ystem (STS) is an interplay of humans, organizations and technical systems. STSs are
distributed systems where a number of autonomous and intentional actors interact in
order to achieve their respective objectives. STSs are characterized by dynamism,
unpredictability and weak controllability. The operational environment is subject to
sudden and unexpected changes, actors may join and leave the system at will, social
dependencies between actors are at risk because of actors’ autonomy, and actors may
fail in achieving their goals. The interests of the actors can be supported
technologically by a software architecture that (i) monitors the actors’ behavior, (ii)
diagnoses failures against correct behavioral models, and (iii) reacts to failures via
compensation actions. We have proposed an architecture based on this cycle in [
Requirements awareness. Lately there has been growing interest in systems that can
adapt to changes in their environment or requirements during run-time. This kind of
adaptive system generally uses some kind of feedback loop to monitor, diagnose and
compensate these adverse situations. We’re interested in studying the requirements
that lead to this feedback loop functionality and we propose a new class of
requirements, called Awareness Requirements (AwReqs). AwReqs are requirements
that refer to other requirements, quality constraints or domain assumptions, and their
success or failure. As a simple example, consider the requirements for a meeting
scheduler. To schedule a meeting, one should know about the agenda of the
participants of the meeting, arrange the meeting (set date/time, book room), and
finally notify all participants about it. As a requirement for adaptation, we may want
to say that the goal of notifying the participants should never fail, or that booking a
room should succeed 90% of the times over any given month. To these AwReqs, the
requirements engineer can attach compensation actions that would get the system
back to normal operation. AwReqs can also refer to quality constraints (QCs) and
domain assumptions (DAs). If there was a QC stating that meetings should have 75%
attendance, an AwReq could say that this quality constraint should succeed 90% over
every week. AwReqs for DAs are analogous. And since AwReqs are requirements
themselves, one could create an AwReq that refers to the success of another AwReq
(a meta-AwReq). Our research on this topic is detailed in [
Future work on contextual requirements includes applying the framework developed so far to security requirements. The main idea is that contexts can influence security requirements and then security has to be analyzed and handled according to the context where the system operates. For example, in an emergency situation (such as fire), a person would allow the rescue team to access his personal data such as his location and his health status, while in a normal situation the same person would have more restricted security concerns. Our interest here is to extend the goal-oriented requirements engineering for security to cope with contextual security requirements introducing new constructs and different forms of reasoning specific for security.
Concerning commitments and self-reconfigurable systems, we are currently
analyzing how a monitor-diagnose-compensate loop changes when we consider
commitments together with goals. We will develop runtime agent reasoning for actors
specified as goals, qualities and commitments. A correctness property, from an actor’s
perspective, would take the form of policies: achieve so and so goals but without
violating so and so commitments. The key here is to formalize the notion of a variant
in terms of both goals and commitments, and then understand adaptation as switching
between variants — similar to the development in [
With respect to awareness requirements, the research is at its beginnings and there
is much to be done. First and foremost, we intend to conduct case studies to assess our
proposal. For that matter, we plan on developing a prototype framework that
implements feedback loops from requirement models, most likely using previous
experience in diagnosing frameworks [
Acknowledgments This work has been partially funded by the EU Commission, through projects SecureChange, COMPAS, NESSOS and ANIKETOS.