Slide sem ttulo

1
TROPOS-T Extending the Tropos Methodology to
Include Requirements Traceability
Jaelson Castro1, Rosa Pinto1, Andréa Castor1,
John Mylopoulos2 1Centro de Informática,
Universidade Federal de Pernambuco, Av. Prof.
Luiz Freire S/N, Recife PE, Brasil 50732-970, (1
5581) 3271 84 30 jbc,rccp,aop_at_cin.ufpe.br 2Dept
. Of Computer Science Unioverity of Toronto, 10
Kings College Road Toronto M5S3G4, Canada, 1
416 978 51 80
2
Outline

• Introduction
• Related Work
• Support for requirements traceability
• Tropos-T
• Conclusions

3
Introduction

• Follow up of the work accepted in SELMAS 2002

• Requirements Traceability in Agent Oriented
  Development Jaelson Castro et all.

• This paper describe

• How to build a subset of a general traceability
  requirements model through a process that helps
  the developers obtain the elements of the
  traceability model that should be stored and what
  relationships these elements should have.
• Medi_at_ Shop case study to illustrate the proposed
  mechanisms and how they fit within the Tropos
  methodology.

4
Related Work

• Orlena Gotel

• She presents an approach based on modelling the
  dynamic contribution structures underlying
  requirements artifacts, which addresses this
  issue.

• Balasubramaniam Ramesh

• He uses reference models to record objects
  and traceability links during the software
  development process.

5
Support for requirements traceability

• General framework Toranzo02

• It includes a meta-model defining the language
  in which traceability models can be defined.
• A set of reference models that can be customized
  within the scope defined by the meta-model. It is
  divided into three sub-models for clarity
• Requirements Management
• Rationale Management
• Design Allocation

6

• Requirements Management sub-model

7

• Rational sub-model

8

• Design sub-model

9
Support for requirements traceability

• Phases of the process for the development of
  traceability information

• Information Gathering.
• Organization and construction of the subset
  traceability model.
• Definition and filling of the traceability
  matrix.

10

• Phases of the process for the development of
  traceability information

11
Tropos

• Phases of software development

• Early requirements, concerned with the
  undestanding of a problem by studying an existing
  organizational setting the output of this phase
  is an organizational model wich includes relevant
  actors and their respective goals use i
• Late requirements, where the system-to-be is
  describe within it is operational environment,
  along with relevant functions and qualities
• Architectural design, where the system's global
  architectural is defined in terms of subsystems,
  interconnected through data and control flows
• Detailed design, where each architectural
  component is defined in further detail in terms
  of inputs, outputs, control, and other relevant
  information

12
Tropos-T - Early requirements
Fig i Model for a Media Shop

• The actors in the SD model should be stored in
  the STAKEHOLDER element of the Requirements
  Management sub-model to be linked to the
  INFORMATIONs that they are responsible for, as
  also the REQUIREMENTs of which they are
  information resources.

13
Tropos-T - Early requirements
Table 2 shows the Organizational Information
related to the Media Shop actor.
Table 3 indicates the diagram that represents
the system actors and their dependencies, in this
case a SD i model.
14
Tropos-T Late requirements
Organizational Map
15
Tropos-T Late requirements
Strategic Rational (SR) Model for Media Shop
16
Tropos-T Late requirements
Rationale Map
Medi_at_
17
Tropos-T - Late requirements
Table 4 System Goals of the Media Shop
Table 5 System Requirements
Table 6 Diagrams of the Media Shop
18
Tropos-T Architectural Design

• Organizational architectural styles

• We adopt the styles defined in organizational
  theory and strategic alliances to design the
  architecture of the system, model them with i,
  and specify in Telos.
• The evolution of the styles can be done with
  respect to software quality attributes identified
  as relevant for distributed and open
  architectures such as multiagent ones.
• In our example, we have left three (soft) goals
  (Availability, Security, Adaptability) in the
  late requirements model.

19
Tropos-T Architectural Design
Table 7 Subjects

• Applying the guidelines of the first and the
  second phases of the process we find the elements
  that are applied to the system

Table 8 Positions
20
Tropos-T Detail Design

• The Design sub model

• It should be used to store information about the
  Detailed Design phase. In this way the DESIGN
  ELEMENTs will be each one of the architectural
  components of the system.

Table 9 Subsystem
21
Products of the Traceability Model Design

• Elements identified by the traceability process

• Table 10 is filled by relating the phases of
  Tropos with the four levels of information for
  the traceability

Table 10 Partial Table to organize the
candidate elements of the traceability model
subset
22
Products of the Traceability Model Design
Table 11 Table to organize the candidate
elements of the traceability model subset
23
Conclusions

• We proposed an extension to the Tropos framework
  to address requirements traceability concerns

• By doing so, we have demonstrated that it is
  possible to provide a sound methodology that also
  supports traceability

• Further work is required to make a comparison
  between issues of requirements traceability for
  objectoriented systems versus agent-oriented
  ones.

• Proper tool support for traceability in the
  context of an agent-oriented software development
  environment is another topic that needs to be
  addressed.

24
Definition of Agent" and Type of Agent

• A weak notion of agency

Autonomy - agents operate without the direct
intervention of humans or others, and have some
kind of control over their actions and internal
state Social ability - agents interact with
other agents (and possibly humans) via some kind
of agent-communication language Reactivity -
agents perceive their environment, (which may be
the physical world, a user via a graphical user
interface, a collection of other agents, the
INTERNET, or perhaps all of these combined), and
respond in a timely fashion to changes that may
occur Pro-activeness - agents do not simply act
response to their environment, they are able to
exhibit goal-directed behavior by taking the
initiative.
25
Definition of MAS (Multi-Agent System)

• MAS a system composed of multiple,
  interacting agents.

Interacting everything that occurs between
agents (agent-agent interaction) and between
agents and their environment (agent-environment
interaction). Agents can interact directly via
communication (by exchanging information) and
indirectly via their environment (by passively
observing one another or by actively carrying out
actions that modify the environmental
state). Interaction may result in changes in the
internal state and the future course of activity
of an agent.
26
Definition of Large Scale Multi-Agent System

• Large-scale multi-agent system encompasses
  multiple types of agents, each of them having
  distinct agency properties, and it needs to
  satisfy multiple stringent requirements such as
  reliability, security, adaptability,
  interoperability, scalability, maintainability,
  and reusability.

27
Agents vs Objects

• Differences between agents and objects

In the degree to which agents and objects are
autonomous. An object has control over its state,
but an object does not exhibit control over its
behaviour Notion of flexible (reactive,
pro-active, social) autonomous behaviour. The
standard object model has nothing what ever to
say about how to build system that integrate
these types of behaviour Agents are each
considered to have their own thread of control
in the standard object model, there is a single
thread of control in the system.