Thaysa Paulo - Gerencia de Projetos

UNIVERSIDADE FEDERAL DE PERNAMBUCO
PS-GRADUAO EM CINCIA DA COMPUTAO

CENTRO DE INFORMTICA
RASTREAMENTO DE REQUISITOS
Autor
Paulo Csar de Oliveira

Thaysa Suely Beltro Paiva
Orientador
Prof. Jaelson Freire Brelaz de Castro

Recife, Julho 200
2009
Universidade Federal de Pernambuco

Centro de Informtica
Resumo
Este trabalho apresenta um estudo a cerca do estado da arte de diferentes

abordagens na rea de rastreamento de requisitos. Foram estudadas trs
abordagens mais atuais da rea de rastreamento de requisitos, e realizada
uma anlise a cerca dessas abordagens, com o objetivo de extrair o que tem
de melhor e mais atrativo para a rea em estudo. Um diferencial encontrado
neste trabalho foi a utilizao de rastreamento de requisitos em sistemas
orientados a agentes.
ndice
Resumo......................................................................................................... 2
ndice .......................................................................................................... 3
ndice de Figuras.......................................................................................... 5
ndice de Tabelas ......................................................................................... 7
Lista de Siglas .............................................................................................. 8
1.
Introduo ............................................................................................ 9
1.1 Motivao ......................................................................................... 9
1.2 Objetivos........................................................................................... 9
1.3 Organizao dos Captulos .................................................................... 9
2.
Rastreamento de Requisitos ................................................................ 11
3.
Uma Abordagem Baseada em Regras para Gerao Automtica de
Relaes de Rastreamento em Sistemas Orientados a Agentes .................... 15

3.1 O Modelo Prometheus........................................................................ 16
3.2 Codificao JACK............................................................................... 20
3.3 Princpios da Abordagem Baseada em Regras ......................................... 24
3.4 Relaes de Rastreamento .................................................................. 27
3.5 Regras de Rastreamento..................................................................... 30
4.
Uma Abordagem para Apoiar o Rastreamento em Tropos .................... 35

4.1 Suporte Rastreamento de Requisitos .................................................. 35
4.2 Tropos ............................................................................................ 38
4.3 Estudo de Caso ................................................................................. 39
5.
Rastreamento Centrado em Metas Usando Virtual Plumbines para Manter
a Qualidade de Sistemas Crticos ................................................................ 46

5.1 Conceitos Iniciais .............................................................................. 47
5.2 Rastreamento Centrado em Metas - GCT ................................................ 47
5.3 Mtodos de Avaliao de Qualidade QAMs ........................................... 49
5.4 Modelagem de Metas ......................................................................... 50
5.5 Avaliao de Metas ............................................................................ 51
5.6 Ligando QAMs e Metas ....................................................................... 51
5.7 Grafo Cruzado .................................................................................. 52
5.8 Condies de Guarda ......................................................................... 53
5.9 Detectando Pontos de Impacto ............................................................ 54
5.10 Um Exemplo de Segurana Crtica ....................................................... 55
6.
Anlise das Abordagens de Rastreamento de Requisitos...................... 59
7.
Concluses ......................................................................................... 61
Referncias Bibliogrficas ........................................................................... 62
ndice de Figuras
Figura 1. Trajetria de um requisito ........................................................... 14

Figura 2. Exemplo de um diagrama resumido do sistema de livraria
(CYSNEIROS & ZISMAN, 2007). .................................................................... 19
Figura 3. Exemplo de um diagrama resumido de agente da livraria
Figura 4. Trecho da implementao do SecurityManager na linguagem JACK
Figura 5. Trecho da implementao do plano SignIn em JACK (CYSNEIROS &
ZISMAN, 2008). .......................................................................................... 22
Figura 6. Trecho da implementao do evento UserLogin em JACK
Figura 7. Trecho da implementao do evento LoginResponse em JACK
Figura 9. Viso da Abordagem Baseada em Regras (CYSNEIROS & ZISMAN,
2008). ....................................................................................................... 25
Figura 10. Modelo de Regra de Rastreamento (CYSNEIROS & ZISMAN, 2007).
................................................................................................................. 31
Figura 11. Exemplo da Regra de Rastreamento de uma Dependncia
Figura 12. Exemplo da Relao de Rastreamento. ....................................... 34
5
Figura 13.
13 Sub-modelo de Gerenciamento de Requisitos (PINTO et al., 2004)
................................................................................................................. 36
Figura 14. Sub-modelo de Projeto (PINTO et al., 2004) ............................... 37
Figura 15. Sub-modelo de Raciocnio (PINTO et al., 2004) .......................... 38
Figura
Figura 16. Diagrama de Atores do Media Shop (PINTO et al., 2004) ............. 40
Figura 17. Diagrama de Raciocnio do Sistema (PINTO et al., 2004) ............. 43
Figura 18. Grafo NFR (PINTO et al., 2004) ................................................... 44
Figura 19. Viso Geral do GCT (CLELAND-HUANG, 2008) ............................ 49
Figura 20. Algoritmo EVALUATE (CLELAND-HUANG, 2008) ......................... 53
Figura 21. Metas Primrias para o Simulador da Estao de Fora mostrando
QAMs para dois cenrios especficos de mudana. (CLELAND-HUANG, 2008)
................................................................................................................. 56
ndice de Tabelas
Tabela 1. Tipos de Rastreamento de Requisitos ......................................... 12

Tabela 2. Matriz de Rastreabilidade ........................................................... 13
Tabela 3.Tipos
de Relaes de Rastreamento (CYSNEIROS & ZISMAN, 2008).
3.
................................................................................................................. 27
Tabela 4. Matriz de Rastreabilidade entre Posies e Argumentos (PINTO et
al., 2004) ................................................................................................... 45
Tabela 5. QAMs do Simulador da Estao de Fora (CLELAND-HUANG, 2008)
................................................................................................................. 57
Lista de Siglas
AOS - Agent Oriented System

GCT - Goal-Centric Traceability
IBS - Ice Breaker System
NFR - Non-Functional Requirements
PCE - Process Centric Environment
QAM - Quality Assurance Management
SLATE - System Level Automation Tool for Engineers
SPE - Software Performance Execution
UML - Unified Modeling Language
XML - eXtensible Markup Language
1.
Introduo
Este Captulo apresenta a motivao, os objetivos
e como o presente
trabalho est organizado.
1.1 Motivao
Este trabalho teve como motivao principal realizar um estudo a cerca de
trs abordagens diferentes e atuais na rea de rastreamento de requisitos,
duas delas abordando princpios diferentes em cima de sistemas orientados
a agentes. As abordagens analisadas neste trabalho so as mais atuais e que
trazem aspectos interessantes a serem estudados em rastreamento de
requisitos.
1.2 Objetivos
Este trabalho teve como objetivo realizar um estudo a cerca de trs
diferentes abordagens mais recentes encontradas na rea de rastreamento
de requisitos em sistemas orientados a agentes. Aps avaliar cada uma das
abordagens em estudo, este trabalho tambm tem como objetivo realizar
uma anlise comparativa entre essas abordagens, de modo a encontrar o que
elas tm em comum, e o que difere uma das outras.
1.3 Organizao dos Captulos

Os captulos deste trabalho esto organizados da seguinte forma:
Captulo 1 Este Captulo apresenta uma introduo ao trabalho, com a
motivao e os objetivos do mesmo, alm da organizao de todo o trabalho.
Captulo 2 Neste Captulo apresentada uma breve descrio a cerca de

rastreamento de requisitos, para prover a ponte deste captulo com os
demais que se seguem.
Captulo 3 Este Captulo apresenta Uma Abordagem Baseada em Regras
para Gerao Automtica de Relaes de Rastreamento em Sistemas
Orientados a Agentes.
Captulo 4 - Neste Captulo apresentada Uma Abordagem para Apoiar o
Rastreamento em Tropos.
Captulo 5 Este Captulo apresenta O Rastreamento Centrado em Metas
Usando Virtual Plumbines para Manter a Qualidade de Sistemas Crticos.
Captulo 6 Neste Captulo apresentada Uma Anlise das Abordagens de
Rastreamento de Requisitos, vistas nos Captulos 3, 4 e 5.
Captulo 7 Apresenta as concluses deste trabalho.
10
2.
Rastreamento de Requisitos
O rastreamento de requisitos pode ser definido como uma tcnica utilizada

para prover um relacionamento entre os requisitos, a arquitetura e a
implementao final do sistema (EDWARDS & HOWELL, 1991). Ele auxilia na
compreenso dos relacionamentos existentes entre os requisitos de software
ou entre artefatos de requisitos, sua arquitetura e sua implementao. Esses
relacionamentos permitem aos projetistas mostrar que o projeto atende aos
requisitos. O rastreamento tambm apoia a deteco precoce daqueles
requisitos
no
atendidos
pelo
software
(PALMER,
1997).
Segundo
Sommerville, existem muitas relaes entre requisitos em si e entre

requisitos e o projeto do sistema (SOMMERVILLE, 2003).
O rastreamento de requisitos pode ser implementado por um conjunto
de elos ou ligaes (links) entre os requisitos inter-relacionados, entre os
requisitos e suas fontes, entre os requisitos e as razes bsicas de suas
proposies e entre os requisitos e os componentes que os implementam.
A Tabela 1 mostra a definio de alguns tipos de rastreamento de
requisitos definidos por Maquioni (MARQUIONI, 2004).
11
Tabela 1. Tipos de Rastreamento de Requisitos
Tipo de Rastreamento
Descrio
Link do requisito s pessoas ou
Requisitos Fontes
documentos
que
especificaram
requisito.
Requisitos Razo
Link do requisito com uma descrio

de porque foi especificado. Pode
ser uma destilao de informaes
de vrias fontes.
Requisitos Requisitos
Link
do
requisito
com
outros
requisitos que sejam, de alguma

maneira, dependentes dele. Deve ser
um link de mo dupla (depende e
dependente de).
Requisitos Arquitetura
Link
do
requisito
com
os
subsistemas onde estes requisitos

esto
implementados.
Particularmente
subsistemas
desenvolvidos
importante
estiverem
por
se
os
sendo
subcontratados
diferentes.
Requisitos Design
Link do requisito com hardware ou

componentes de software especficos
no sistema que so usados para
implementar o requisito.
Requisitos Interface
Link do requisito com as interfaces

de
sistemas
externos
que
sero
usados na proviso dos requisitos.
De forma a facilitar o rastreamento de requisitos, normalmente so

utilizadas tabelas de rastreabilidade, que criam associaes entre os
requisitos. A matriz de rastreabilidade mostra a ligao entre os requisitos,
12
onde a linha dependente da coluna e a coluna depende da linha. Trata-se,

portanto, de uma forma de visualizao grfica do rastreamento de
requisitos. Esta matriz demonstra de que forma um requisito influencia em
outro, possibilitando uma anlise do impacto de uma alterao do requisito.
A Tabela 2 exibe um exemplo de uma matriz de rastreabilidade.
Tabela 2. Matriz de Rastreabilidade
R1
R2
R1
R2
R3
R3
R4
X
X
R5
X
X
X
R4
R5
Nesse exemplo acima, R1 dependente de R3 e R5; R2 dependente

de R5 e R6, e assim por diante. Se por acaso houver a necessidade de alterar
o requisito R4, ento os requisitos R2 e R5 vo ser afetados, pois eles
dependem de R4. Dessa forma deve ser avaliado o impacto que essa
alteraco em R4 ir causar em R2 e R5.
O rastreamento de requisitos pode ser visto como uma habilidade de
acompanhar e descrever a vida de um requisito, em ambas as direes. A
pr-rastreabilidade documenta o contexto a partir do qual emergem os
requisitos; a ps-rastreabilidade vincula os requisitos ao desenho do sistema
e sua implementao (DAVIS, 1993). A Figura 1 mostra como as ligaes
permitem acompanhar a trajetria de um requisito, em ambas as direes.
13
Figura 1. Trajetria de um requisito
Na primeira parte temos o rastreamento forward-to (para frente), que

liga documentos obtidos no processo de elicitao a requisitos relevantes, e
o rastreamento backward-from (para trs), que liga requisitos s suas fontes.
Na segunda parte temos o rastreamento forward-from, que liga
requisitos a artefatos de desenho e implementao e rastreamento
backward-to, que liga artefatos de desenho e implementao de volta a

requisitos.
O rastreamento tambm pode ser identificado como a habilidade de
descobrir a histria de toda caracterstica do sistema, dado que os impactos
de mudanas nos requisitos podem ser identificados (HAMILTON & BEEBY,
1991); ou ainda como a habilidade de permitir que mudanas em qualquer
artefato - requisitos, especificao e implementao - sejam rastreadas
atravs do sistema (GREENSPAN & McGOWAN, 1978).
14
3. Uma Abordagem Baseada em Regras para Gerao

Automtica de Relaes de Rastreamento em Sistemas
Orientados a Agentes
Dentre as abordagens existentes na rea de rastreamento de requisitos em
sistemas orientados a agentes AOS (LUCK, 1999), encontra-se a abordagem
que descrita neste captulo: Uma Abordagem Baseada em Regras para
Gerao Automtica de Relaes de Rastreamento entre modelos de projeto e
especificaes de cdigo em sistemas orientados a agentes (CYSNEIROS &
ZISMAN, 2008).
Sistemas Orientados a Agentes tm sido utilizados para apoiar o
desenvolvimento de aplicaes distribudas, complexas, abertas, altamente
interativas e dinmicas. Essas aplicaes requerem sistemas com softwares
autnomos que combinam comportamentos reativos e pr-ativos e que so
capazes de simular habilidades sociais, tais como cooperao, coordenao e
negociao. No desenvolvimento de software orientados a agentes, os
sistemas so compostos por entidades computacionais autnomas e
flexiveis, o que tem retratado desse novo paradigma de desenvolvimento
orientado a agentes muito sucesso em diversas reas de aplicao, dentre
elas a de telecomunicaes, a de finanas, a de e-commerce, entre outras.
Foi com o foco nos avanos de sistemas orientados a agentes e em sua
importncia,
que
os
autores
Cysneiros
&
Zisman
propuseram
uma
abordagem de rastreamento de requisitos que apoiasse o desenvolvimento

15
orientado a agentes (CYSNEIROS & ZISMAN, 2007). Essa abordagem foi

realizada em cima de modelos projetados na ferramenta Prometheus
(PADGHAM & WINIKOFF, 2004) e em especificaes de cdigo implementadas
na ferramenta JACK (WINIKOFF, 2005). A Prometheus foi escolhida como base
desta abordagem, por apresentar suporte a maioria das fases do ciclo de vida
do desenvolvimento do processo da Engenharia de Software, e por ser
amplamente utilizada em academias e em indstrias de software. A
ferramenta JACK foi escolhida por ser bastante utilizada nas indstrias de
software, por incluir todos os componentes da linguagem de programao
Java, alm de oferecer extenses para possibilitar a implementao de
aspectos comportamentais de agentes (CYSNEIROS & ZISMAN, 2007).
3.1 O Modelo Prometheus

Antes de apresentar os princpios da abordagem baseada em regras, uma
breve explicao a cerca do modelo Prometheus mostrada nesta seo,
atravs de um exemplo prtico de parte de um sistema de livraria orientado a
agentes. Esse sistema tem suporte s principais funcionalidades de uma
livraria, tais como venda de livros, validao de clientes no sistema e
gerenciamento de catlogos de livros e clientes.
A metodologia Prometheus consiste em vrios diagramas e descritores
para representar o projeto de determinado sistema orientado a agentes.
Exemplos de descritores, pode-se dizer que so os diferentes tipos de
artefatos, tais como agentes, percepes, aes, objetivos, base de dados,
regras, planos, mensagens e capacidades.
16
Na ferramenta Prometheus pode-se encontrar os seguintes conceitos:
Agente: Representa uma entidade autnoma em um ambiente;
Percepo: Representa os dados recebidos por um ambiente;
Ao: Representa como um agente afeta um ambiente;
Objetivo: descreve a meta de um agente a ser realizada, algumas
atividades que o mesmo pretende alcanar, ou um estado que deve ser

evitado ou mantido uma vez que a meta alcanada;
Base de Dados: representa a informao que um agente externo
precisa ter acesso ou representa o conhecimento do agente sobre o

ambiente ou sobre si mesmo;
Regra: Especifica alguma funcionalidade e agrupa um conjunto
relacionado de objetivos, percepes, aes e base de dados;
Plano: uma sequncia de aes que o agente pode realizar para
atingir seu objetivo;
Mensagem: Representa a comunicao entre os agentes;
Capacidade:
Representa
funcionalidade
de
um
agente
encapsular percepes, base de dados, aes, mensagens, planos e

capacidades internas.
A ferramenta Prometheus possibilita a criao de vrios diagramas,
dentre eles o diagrama de objetivos, o diagrama de regras, o cenrio de
casos de uso, diagrama de processos, diagrama resumido de sistema,
diagrama resumido de agente, etc.
17
Nas Figuras 2 e 3 so mostrados os dois exemplos utilizados na

abordagem de (CYSNEIROS & ZISMAN, 2007)para exemplificar os conceitos
relatados logo acima.
A Figura 2 retrata um exemplo do diagrama resumido do sistema da
livraria. Este diagrama especifica como um sistema orientado a agentes
interage com o ambiente. Os elementos principais do diagrama so os
agentes (representados por um retngulo com a imagem de um ator dentro
dele), as percepes (representadas pelos elementos estrelares) as quais os
agentes respondem, as aes realizadas pelos agentes (representadas pela
seta retangular), as mensagens trocadas entre os agentes (representadas
pelo envelope retangular) e a base de dados externa acessada pelos agentes
(no representada nessa figura). O sistema de livraria orientado a agentes
utilizado neste exemplo composto pelos agentes Sales Assistant, Stock
Manager, Credit Card e Security Manager. O agente Sales Assistant responde

percepo Book Details, que contem informaes sobre como comprar um
livro, e percepo Keyword Search, que contem informaes sobre a busca
no catlogo de livros. O agente Sales Assistant tambm envia mensagens de
book catalogue e requesting a purchased item para serem removidos do

stock, respectivamente. Os outros elementos do diagrama so representados
de forma similar ao descrito.
18
Figura 2. Exemplo de um diagrama resumido do sistema de livraria (CYSNEIROS &

ZISMAN, 2007).
A Figura 3 mostra o diagrama resumido de agente, que representa em

detalhes o modelo de um agente, que no caso do sistema da livraria, trata-se
do agente Security Manager. Os principais elementos desse diagrama so as
aes (representadas pela seta retangular), os planos (representados pela
elipse), a base de dados (representada pelo smbolo de armazenamento de
dados)
as
percepes
(representadas
pelos
elementos
estrelares).
Acompanhando a sequncia lgica desse diagrama, na presena da

percepo Login Details, o plano Validate User executado. O plano consiste
em chegar se a informao de login do usurio est de acordo com a
informao armazenada na base de dados User DB. Caso a resposta seja
positiva, a ao Show Main Screen executada; caso contrrio, a ao Show
Invalid Login Message lanada. Os outros elementos do diagrama esto

representados de forma similar.
19
Figura 3. Exemplo de um diagrama resumido de agente da livraria

(CYSNEIROS & ZISMAN, 2007).
Estes dois exemplos acima foram mostrados apenas para esclarecer
todas as entidades presentes na ferramenta Prometheus que foi utilizada na
abordagem em estudo.
3.2 Codificao JACK

A linguagem JACK baseada na linguagem de programao Java. Ela possui
uma extenso de Java com construes orientadas a agentes, tais como
classes, interfaces, mtodos e outros usos vlidos de Java de declaraes e
confirmaes, tais como pacotes, atributos, definies de mtodos e
imports. Uma aplicao em JACK composta por muitas especificaes de

cdigo fonte, representando agentes, planos, eventos, capacidades e bases
de dados (CYSNEIROS & ZISMAN, 2008)
Em JACK, uma especificao de um agente usada para definir o
comportamento de um agente de software. Isto inclui as capacidades do
agente, os tipos de mensagens e eventos que o agente responde, os eventos
criados pelo agente, as bases de dados utilizadas pelo agente para
20
armazenar informaes e os planos dos agentes usados para alcanar os

objetivos.
A
Figura
mostra
um
trecho
da
implementao
do
agente
SecurityManager em JACK. Esse agente herda as principais funcionalidades

da classe Agent (extends). Este trecho contm declaraes para eventos
(#posts e #handles), planos e base de dados. Um evento #post representa
um evento que o agente pode criar, enquanto um evento #handles
representa um evento que o agente responde. Um plano #uses especifica um
plano que foi executado pelo agente, enquanto os dados #private identifica
uma base de dados que o agente pode usar para armazenar as informaes.
Tambm detalhado nesse exemplo um atributo bookstore, que prov a
interface entre o agente e o ambiente, alm da definio de vrios mtodos e
processos de percepo do ambiente e a criao de eventos.
Uma especificao de um plano descreve a sequncia de aes que um
agente pode executar quando um evento ocorre. A Figura 5 apresenta um
exemplo da implementao do plano SignIn em JACK. Este plano manipula o
evento UserLogin (#handles event UserLogin ev;) e o envio do evento
LoginResponse (#sends event LoginResponse ev1;) e usa a base de dados dos

clientes (#uses data CustomerDB customers;). Os detalhes da implementao
em JACK dos eventos UserLogin e LoginResponse esto apresentados nas
Figuras 6 e 7, respectivamente. A Figura 8 descreve a base de dados
CustomerDB em JACK.
21
Figura 4. Trecho da implementao do SecurityManager na linguagem

JACK (CYSNEIROS & ZISMAN, 2007).
Figura 5. Trecho da implementao do plano SignIn em JACK (CYSNEIROS &

ZISMAN, 2008).
22
Figura 6. Trecho da implementao do evento UserLogin em JACK



23
3.3 Princpios da Abordagem Baseada em Regras

Ao se tratar da abordagem baseada em regras propriamente dita, ela suporta
a gerao de rastreamento e a verificao da completude dos modelos
gerados durante as diferentes fases do ciclo de vida do desenvolvimento de
sistemas orientados a agentes, alm de apoiar-se no uso de regras
representadas na extenso de XQuery (XQuery, 2005).
A abordagem de Cysneiros e Zisman restrita a modelos de projetos
gerados pela ferramenta Prometheus, e a especificao de cdigos em JACK
utilizando um edito de texto genrico.
Visando suportar a heterogeneidade entre e modelos e ferramentas
utilizadas durante o ciclo de vida de desenvolvimento de software, os
modelos foram representados em XML. Dentre os motivos existentes para
tornar o XML a base dessa abordagem em estudo, pode-se citar:
XML ter se tornado uma linguagem que suporta a permutao de
dados entre diferentes ferramentas e aplicaes;
A existncia de um grande nmero de aplicaes que usa XML para
representar as informaes internamente ou como padro de formato
de exportao;
Permitir o uso de XQuery como uma forma padro de expressar as
regras de rastreamento e de verificao de completude.
O processo de abordagem de Cysneiros e Zisman apresentado na

Figura 9. Inicialmente, os modelos para serem rastreados e verificados sua
completude foram gerados usando as ferramentas Prometheus e Notepad.
24
Esses modelos foram traduzidos para o formato XML (chamados XML_based

Models na figura) pelo componente Model Translator, sempre que as
ferramentas utilizadas para criar os modelos no permitam a gerao destes
em um formato XML. A traduo dos modelos para o formato XML baseada
no XML Schema proposto para modelos. A ferramenta Prometheus permite
que seus modelos sejam exportados em formato XML, e portanto, no h a
necessidade de utilizar o componente de traduo para eles, enquanto que a
especificao de cdigo em JACK fez com que os autores dessa abordagem
desenvolvessem um tradutor utilizando o gerador de parser ANTLR (PARR,
2007).
Figura 9. Viso da Abordagem Baseada em Regras (CYSNEIROS & ZISMAN,

2008).
25
Os componentes XML_based models e rules so usados como entradas

para o componente Traceability_Completeness_Checking Engine auxilia na
gerao da relaes de rastreamento entre os modelos e na identificao da
ausncia de elementos baseado nas regras. Este componente tambm usa
Wordnet (WORDNET) para suportar a identificao de sinnimos entre os
nomes dos elementos nos modelos. As relaes de rastreamento e a
identificao da ausncia de elementos esto representados em um
documento
XML
(na
Figura
9,
no
documento
Traceability_Relations_Missing_Elements). importante utilizar documentos

separados para representar as relaes de rastreabilidade e a ausncia de
elementos para preservar os modelos originais, alm de permitir o uso desse
modelos em outras aplicaes e ferramentas e a gerao de relaes ser
utilizada na identificao de outras relaes de rastreamento que dependam
da existncia de relaes previamente identificadas (por exemplo, relaes
primitivas e dependentes).
Segundo (CYSNEIROS & ZISMAN, 2008), relaes de rastreamento que
no dependam da existncia de outras relaes so relaes primitivas,
enquanto que aquelas que dependam da existncia de outras relaes so
denominadas de relaes dependentes.
As relaes de rastreamento e suas respectivas propriedade so
exibidas em diferentes formas, como por exemplo, rvores e matrizes,
atravs
do
componente
Tracability
Management.
componente
Completeness Checking Management suporta a gerao de elementos

ausentes identificados e da correo de inconsistncias entre os modelos.
26
Foram identificados seis diferentes tipos de relaes de rastreamento entre

os elementos dos modelos de projetos elaborados na ferramenta Prometheus
e as especificaes de cdigo em JACK. Esses tipos sero explicados
detalhamente na prxima subseo.
3.4 Relaes de Rastreamento

Com base nos estudos realizados com a metodologia utilizando a ferramenta
Prometheus e a anlise da linguagem JACK, com a experincia dos autores
(CYSNEIROS & ZISMAN, 2007) na rea de rastreamento de requisitos de
software e com os tipos de relaes de rastreamento propostas pela
literatura (POHL, 1996) (RAMESH & JARK, 2001),foram identificadas 6
diferentes tipos de relaes entre os vrios elementos dos modelos
utilizados na abordagem em estudo.
A Tabela 3 apresenta os diferentes tipos de relaes encontradas para
os principais elementos da ferramenta Prometheus e da linguagem JACK.
Tambm pode ser mostrado na Tabela 3, que alm das relaes de
sobreposies, bi-direcionais , que a direo de uma relao representada
a partir de uma linha [i] para uma coluna [j] (por exemplo, "a regra
Prometheus utilizado no agente JACK").
Tabela 3.Tipos de Relaes de Rastreamento (CYSNEIROS & ZISMAN, 2008).
27
Os tipos de relaes de rastreabilidade identificados na abordagem de

Cysneiros e Zisman so os seguintes (CYSNEIROS & ZISMAN, 2007):
Overlaps Neste tipo de relao, um elemento e1 overlaps com um

elemento e2 (ou um elemento e2 overlaps com o elemento e1), se e1 e e2
referem-se a aspectos comuns do sistema orientado a agentes ou de
mesmo domnio. Por exemplo, existe uma relao de overlaps entre o
agente Security Manager em Prometheus e o agente SecurityManager em
JACK, desde que eles se refiram a aspectos comuns do sistema. Neste
caso, trata-se de um exemplo de uma relao primitiva.
Contributes (Contributed by) Neste tipo de relao , um elemento e1

contributes para um elemento e2, se e1 assiste com a realizao ou
cumprimento do outro elemento e2. Por exemplo, uma relao de
contributes existe entre o agente Security Manager em Prometheus e o

mtodo login em JACK. Esta uma relao secundria, pelo fato do
mtodo login criar um evento Login, que mantm uma relao de
overlaps com o objetivo Login em Prometheus, que alcanada pelo

agente Security Manager.
Uses (Used by) Neste tipo de relao, um elemento e1 uses um

elemento e2, se e1 requer a existncia de e2 para alcanar seu objetivo.
Por exemplo, existe uma relao de uses entre o plano Validate User em
Prometheus e o agente Security Manager em JACK. Neste caso o agente
Security Manager uses o plano Verify User que overlaps com o plano
28
Validade User em Prometheus. Este um exemplo de uma relao

secundria devido a existncia de uma relao de overlaps..
(Created
Creates (Crea
ted by) Neste tipo de relao, um elemento e1 creates um
elemento e2, se e1 gera o elemento e2. Por exemplo, existe uma relao
secundria create entre o agente SecurityManager em JACK e a ao
Show Invalid Login Message em Prometheus, desde que o agente

SecurityManager contem o mtodo showInvalidLogin que gera uma
relao de overlaps com a ao Show Invalid Login Message em
Prometheus.
Achieves (Achieves by) Neste tipo de relao, um elemento e1 achieves

um elemento e2, se e1 satisfaz as expectativas e necessidades de e2.
Planos em JACK descrevem uma sequncia de aes que um agente pode
passar quando um certo evento ocorre. Em JACK, objetivos so
representados implicitamente como eventos que podem ativar os planos.
Portanto, se h um objetivo em Prometheus que tem uma relao de
overlaps com um evento em JACK e um plano em JACK responde para

este evento, ento pode-se dizer que existe uma relao de achieves
entre o plano em JACK e o objetivo em Prometheus. Por exemplo, existe
uma relao secundria achieves entre o plano VerifyUser em JACK e o
objetivo Login em Prometheus, desde que o plano VerifyUser responde ao
evento Login que gera uma relao de overlaps com o objetivo Login.
Depends on (Is Dependent) Neste tipo de relao, um elemento e1

depends on um elemento e2, se a existncia de e1 depende da existncia
de e2, ou se as alteraes em e2 devem ser refletidas em e1. Por
29
exemplo, o plano Validate User em Prometheus depends on do mtodo
showInvalidLogin em JACK. Uma relao secundria vista quando o

mtodo showInvalidLogin
gera uma relao de overlaps
com a ao
Show Invalid Login Message em Proemetheus, e como o plano est

definido por uma sequencia de aes, ele depende da existencia de
mtodos que overlaps com essas aes.
3.5 Regras de Rastreamento

As regras de rastreamento (CYSNEIROS & ZISMAN, 2008), usadas nesta
abordagem em estudo e que suporta a gerao automtica de relao de
rastreamento, so compostas por algumas partes principais. A Figura 10
mostra um modelo geral representando um pseudo-cdigo para as regras.
Neste modelo, os elementos entre colchetes ([, ]) so opcionais, e
fi(fi+1...(fi+j(.))...) representa uma composio de funes e declaraes de if
forem usadas nas regras. Essas funes so funes XQuery ou funes
extras que foram implementadas para suportar a abordagem em estudo.
30
Figura 10.
10. Modelo de Regra de Rastreamento (CYSNEIROS & ZISMAN, 2007).
Logo abaixo seguem as partes da regra de rastreamento:
Parte 1: Esta parte consiste na identificao de regras que contm um
identificador nico (RuleID), uma prioridade da regra (RulePrority) indicando
se trata-se de uma regra primitiva (priority 1), ou uma regra dependente
(priority 2), o tipo da regra (RuleType), o tipo do elemento de origem a ser
traado (ElemTypeA), o tipo do elemento alvo a ser traado (ElemTypeB), e
31
uma breve descrio da regra (Description). A prioridade da regra usada

para identificar se a regra primitiva ou dependente e prosseguir com a
execuo das regras; por exemplo, regras com prioridade 1 so executadas
antes das regras com prioridade 2, desde que estas ltimas dependam da
existncia de relaes geradas pelas regras com prioridade 1. Este tipo de
regra baseado no tipo de relao de rastreamento gerado pela regra. A
Figura 11 mostra um exemplo dessa primeira parte da regra. Ela est
representada em XQuery para gerar a relao de dependncia entre os
mtodos em JACK e os planos em Prometheus.
Parte 2: Esta parte consiste em proposies de XQuery que so formadas
para outras subpartes. A primeira subparte (DECLARE) contem declaraes de
namespaces, documentos e uma sequncia de elementos usados pela regra.

A declarao dos documentos e a sequncia de elementos so descritos
como expresses Xpath. Por exemplo, na Figura 11, existem declaraes de
(a) Classes em Java similares, (b) Modelos JACK e Prometheus (JACK.xml e
BookShop.pd) e (c) sequncias de elementos de mtodos em JACK e planos

em Prometheus para serem comparados ($methods e $plans).
A segunda subparte (FOR) itera os elementos das sequncias e vincula
esses elementos a variveis ($elema $elemb $elemc). A Figura 11 mostra a
primeira declarao que vincula os planos em Prometheus e os mtodos em
JACK, em variveis $plan e $method, respectivamente.
32
Figura 11.
11. Exemplo da Regra de Rastreamento de uma Dependncia
A terceira subparte (CONDITION) define a condio da parte da regra
que deve ser satisfeita. Condies so definidas por clusulas where-
expression de uma clusula for em XQuery ou pela parte test-expression de

uma expresso if-then-else em XQuery. A condio dessa parte da regra usa
funes e expresses XQuery built-in, e funes extras em Java que foram
desenvolvidas pelos autores (CYSNEIROS & ZISMAN, 2007).
33
No exemplo da Figura 11 a expresso where na condio da regra

checa se o plano em Prometheus contem pelo menos uma ao que tem
relao de overlaps com um mtodo em JACK. Por exemplo, o mtodo
showInvalidLogin em JACK tem relao de overlaps com a ao em

Prometheus showInvalidLoginMessage. Na sequncia, o plano Validate User
em Prometheus uses e ao ShowInvalidLoginMessage em Prometheus.
Assim a condio where se mantm na parte da regra.
A quarta subparte (ACTION) especifica a parte da consequncia da regra
onde as condies so satisfeitas. Ela descreve as relaes de rastreamento
(RELATION). A avaliao da parte da consequncia consiste na escrita das
relaes de rastreamento no documeno XML Traceability_Relation. A Figura
12 apresenta parte desse documento com o resultado da execuo da regra
RulePJ5b da Figura 11 para o plano Validate User em Prometheus e o mtodo

showInvalidLogin em JACK. A relao de rastreamento contem informao
sobre a
respectiva
regra
(RuleID),
seu tipo
(RelType),
elementos
relacionados (element <Element>).
Figura
12.
12. Exemplo da Relao de Rastreamento.
34
4. Uma Abordagem para Apoiar o Rastreamento em Tropos

O processo de Engenharia de Requisitos suporta o entendimento das metas
dos stakeholders, assim como o refinamento destas metas em requisitos.
Uma atividade importante neste processo manter uma ligao entre
requisitos e artefatos do processo de desenvolvimento.
Existe tambm uma grande importncia no relacionamento entre
rastreamento e gerenciamento de configurao. Se a sada de um sistema
no controlado de forma adequada, ser difcil gerenciar links entre eles.
Nesta abordagem, desenvolvida por (PINTO et al., 2004) e (PINTO,
2008), apresentada um framework que pode tambm ser til no contexto
de desenvolvimento orientado a agentes. Foi delineada uma soluo para
aumentar o framework Tropos para suportar rastreabilidade.
4.1 Suporte Rastreamento de Requisitos

Um framework foi apresentado em (TORANZO, 2002) para suportar
rastreamento de requisitos, que inclui um meta-modelo que define a
linguagem em que modelos de rastreamento podem ser definidos, e um
modelo de referncia pode ser customizado dentro do escopo definido no
meta-modelo.
Elementos esto relacionados entre si atravs de ligaes com
associao semntica, com a notao baseada em esteritipos UML. O
modelo de referncias dividido em trs partes chamadas sub-modelos e
so explicadas abaixo:
35
Sub-modelo
rastreamento
Gerenciamento
bem
de
Requisitos:
implementado,
Quando
gerenciamento
de
requisitos beneficiado, facilitando o entendimento, captura,

rastreamento, validao e verificao de requisitos, como
mostrado na Figura 13.
Figura 13.
13. Sub-modelo de Gerenciamento de Requisitos (PINTO et al., 2004)
Sub-modelo de Projeto: utilizado para se referir a qualquer
atividade que crie um artefato, inclusive a implementao, como
pode ser visto na Figura 14.
Sub-modelo de Raciocnio: Identifica e estrutura problemas e
decises tomadas durante o desenvolvimento de software, como
pode ser visto na Figura 15.
36
Figura 14.
14. Sub-modelo de Projeto (PINTO et al., 2004)
Ser esboado um processo que pode ser usado para construir os
modelos vistos: Colheita de Informaes, Estruturao de Informaes e
Construo das Matrizes de Rastreamento. Este processo ser usado
juntamente com a abordagem Tropos que iremos explicar na seo seguinte.
37
Figura
15.
15. Sub-modelo de Raciocnio (PINTO et al., 2004)
4.2 Tropos
Tropos se apia na idia de utilizar conceitos de modelagem de requisitos
para construir um modelo do sistema a ser construdo dentro do ambiente
operacional. Este modelo refinado e estendido incrementalmente, provendo
uma interface para as atividades de desenvolvimento.
A metodologia proposta passa por quatro fases que pode ser utilizado
no modelo espiral ou cascata, so elas:
Requisitos Antecipados: Preocupa-se com o entendimento de um
problema;
38
Requisitos Atrasados:Onde o sistema a ser construdo descrito

dentro de seu ambiente operacional, com funes e qualidade
relevantes;
Projeto Arquitetural: Onde a arquitetura do sistema global
definida em termos de subsistemas, interconectado atravs de
informao, controle e outras dependncias;
Projeto Detalhado: Onde o comportamento de cada componente
da arquitetura mais refinado.
Tropos tem definido estilos arquiteturais para aplicaes arquiteturais,

dinmicas e distribudas como sistemas multiagentes para guiar o projeto da
arquitetura do sistema.
Iremos esquematizar as fases do Tropos atravs de um exemplo de
sistema e-business e efetuar algumas observaes sobre como itens de
rastreabilidade podem ser endereados.
4.3 Estudo de Caso

O sistema Media Shop foi construdo para vender e enviar produtos de uma
loja que vende vrios itens como CDs, vdeos, livros, revistas e jornais. Existe
um catlogo que atualizado periodicamente, que permite ao usurio
escolher o que deseja comprar atravs de buscar por ttulo, autor/artista e
pelo campo de descrio, caso o produto no esteja disponvel, um usurio
pode indicar para que a loja encomende.
39
Este sistema permite que os clientes possam comprar na loja, por

telefone, pela internet. Usa um sistema que facilita a comunicao provido
pela Telecom Cpy, e um sistema financeiro provido pela Bank Cpy.
possvel ainda, ver detalhes de cada produto no catlogo disponvel
pela internet, detalhes como: ttulo, categoria, gnero, autor/artista, breve
descrio, editor, informaes e referncias internacionais, data, preo e
algumas imagens quando disponvel.
REQUISITOS ANTECIPADOS: Baseado nas descries acima possvel
ser criado um modelo de um ambiente organizacional, mostrado na Figura
16, logo abaixo.
Figura 16.
16. Diagrama de Atores do Media Shop (PINTO et al., 2004)
Quality Packages uma dependncia de softgoal que vai ser

armazenado em EXTERNAL INFORMATION do Sub-modelo de Gerenciamento
de Requisitos. Ele se refere a uma informao externa para o sistema da
organizao. Increase Market Share, Happy Customers, Continuing Business
Goals e Continuous Supply softgoals so ORGANIZATIONAL INFORMATION,

pois estes softgoals fazem parte do mundo do sistema organizacional. Buy
40
Media Item, Consult Catalogue e Media Items so REQUIREMENTS da camada

de gerenciamento.
Os atores do diagrama mostrado na figura anterior podem ser
armazenados como informaes do STAKEHOLDER para ser ligado com
INFORMATION. uma ligao muito importante pois armazena informaes

sobre os stakeholders e suas contribuies para o sistema.
Entendido o ambiente organizacional, possvel ento, decidir
desenvolver um sistema que o suporte.
ANLISE DE REQUISITOS ATRASADOS: Introduzimos contribuies de
softgoals para o modelo suficientemente positivo (++), parcialmente positivo

(+), suficientemente negativo (--) e parcialmente negativo (-), que do
suporte
os
softgoals Security, Availability, Adaptability, Attract New
Customers e Increase Market Share (CASTRO et al., 2002).

Os softgoals foram includos no modelo de requisitos atrasados.
A meta Availability representa a habilidade de agentes de sistema decidir
automaticamente qual navegador de catlogo, carrinho de compras e
arquitetura do processador de encomendas se adequa melhor com as
necessidades do usurio. Para representar Security, proposto na arquitetura
do sistema uma quantidade de estratgias de segurana e deixa o sistema
escolher em tempo de execuo, qual o mais apropriado. Adaptability
significa que o contedo do catlogo, o schema do banco de dados e
modelos arquitetural devem poder ser estendidos automaticamente ou
modificados para integrar uma nova e futura tecnologia web. A meta Attrac
New Customer representado como uma meta SYSTEM GOAL.

41
Todas as atividades mostradas na Figura 17 abaixo que ainda no

foram mencionados so requisitos funcionais. Todos os requisitos funcionais
e no funcionais esto armazenados na informao REQUIREMENTS.
Telecom Cpy e Bank Cpy so novos stakeholders, ento so
adicionados a informao STAKEHOLDERS. Devemos armazenar o Internet
Services e Process On-line Money Transactions na EXTERNAL INFORMATION,

porque ambos pertencem ao mundo externo do sistema, mas que impacta
muito nele.
PROJETO ARQUITETURAL: Os atributos de qualidade que foram
levantados na fase de requisitos atrasados iro guiar o processo de seleo
do estilo arquitetural apropriado. O modelo de raciocnio captura esta
informao, e til para justificar a deciso tomada.
Lidar com requisitos no funcionais e selecionar o estilo do ambiente
organizacional atravs da anlise usando NFR Framework (CHUNG et al.,
2000). Refinam-se os requisitos identificados para gerar sub-requisitos que
ser mais precisos e avaliar estilos organizacionais alternativos, como
mostrado na Figura 18.
42
Figura 17.
17. Diagrama de Raciocnio do Sistema (PINTO et al., 2004)
43
Figura 18.
18. Grafo NFR (PINTO et al., 2004)
Considerando os elementos do Modelo de Raciocnio, possvel
armazenar no elemento SUBJECT, o processo de seleo relacionado ao estilo
organizacional que ser usado. O estilo arquitetural deve ser representado
como POSITION para o SUBJECT. Assim para cada SUBJECT existe um
POSITION relacionado. A notao usada no diagrama NFR (++, +, --, -) para

demonstrar a adequao ou no de um certo estilo arquitetural deve ser
gravado como ligaes entre POSITIONs e cada um dos ARGUMENTs. Os
requisitos no-funcionais sero os ARGUMENTS para cada posio, porque
so motivaes para as decises tomadas. O catlogo de relacionamento
mtuo ser armazenado no elemento CONSTRAINT desde que a deciso
sobre qual estilo ser usado esteja limitado a usar este catlogo. O fato de
escolher um estilo arquitetural baseado na abordagem organizacional e no
44
baseado em estilos arquiteturais tradicionais devero ser armazenadas no

elemento ASSUMPTION. Na Tabela abaixo mostrado o relacionamento entre
elementos POSITION e ARGUMENT.
Tabela 4. Matriz de Rastreabilidade entre Posies e Argumentos (PINTO et
al., 2004)
45
5.
Rastreamento
Centrado
em
Metas
Usando
Virtual
Plumbines para Manter a Qualidade de Sistemas Crticos

Outra abordagem para o rastreamento de requisitos foi desenvolvida por
(CLELAND-HUANG, 2008). A abordagem de Rastreamento Centrado em
Metas Goal-Centric Traceability (GCT), usando Virtual Plumbines
apresentada neste Captulo, utilizando o conceito de relacionamento entre
metas do sistema e modelos de avaliao.
Atravs de algoritmos, processos, tcnicas para a utilizao desta
abordagem, de forma a estabelecer ligaes entre as metas e os modelos de
avaliao, detectar mudana de pontos de impacto, propagao de eventos
de impacto, e avaliar o impacto de mudanas sobre qualidades sistmicas.
Dois estudos de caso so utilizados para demonstrar esta abordagem,
o primeiro prov um exemplo executvel do Sistema de Quebra de Gelo - Ice
Breaker System (IBS) (ROBERTSON & ROBERTSON, 1999). O IBS gerencia

servios para prevenir a formao de gelo nas estradas. O outro estudo de
caso utilizado no trabalho de (CLELAND-HUANG, 2008) o Simulador de
Estaes de Fora, para treinamento de operadores das estaes (BERENBACH
et al., 1991), (BERENBACH & SWANKE, 1984) e (CRONE, 2006). Nosso trabalho
ir focar neste estudo de caso.
46
5.1 Conceitos Iniciais

Antes de tudo, preciso definir o que so Virtual Plumbines. Plumbine
utilizado na indstria da construo civil para avaliar se uma parede est
verticalmente alinhada ou no, que uma qualidade simples, porm crtica.
Da mesma forma, um Virtual Plumbine vai avaliar a conformidade de um
sistema com as metas estabelecidas pelos stakeholders.
A tcnica Rastreamento Centrado em Mtricas cria Virtual Plumbines
para avaliar ao longo do tempo, a conformidade do sistema com as metas
estabelecidas. O GCT foca em metas de qualidades, especificadas como
requisitos no-funcionais ou restries, como desempenho, confiabilidade,
segurana, que so difceis de programar e manter de forma correta em um
sistema (BOEHM et al., 1973) e (CLELAND-HUANG, 2005).
Algumas tcnicas medem atributos especficos de qualidade, por
exemplo, Grafos de Execuo de Desempenho de Software (SPE) avaliam as
metas de tempo de resposta (SEFFAH, 2001); Grafos de Execuo de Sistema
mede o ritmo de transferncia e a latncia (JAIN, 1991); Casos de Uso
Imprprio (ALEXANDER, 2003) e Grafos de Ataque (SHEYNER, 2002) para
medir atributos de segurana. Para o GCT, todas estas tcnicas so
mencionadas como Modelos de Avaliao de Qualidade (QAM).
5.2 Rastreamento Centrado em Metas - GCT

GCT prov um relacionamento entre uma hierarquia de metas e QAMs, de
forma que um conjunto destes modelos possa ser reavaliado quando
47
necessrio. Isto pode ser avaliado atravs do Virtual Plumbine, que ir

verificar se mudanas no sistema impactaram nas metas de qualidade.
Quando ocorre um evento de impacto, o GCT deve identificar um
conjunto inicial de metas afetadas e utilizar um conjunto de QAMs para
reavali-las. Algumas caractersticas do GCT so:
Um modelo de metas que reflete as necessidades de qualidade
dos stakeholders;
Um conjunto de QAMs para avaliar metas de qualidade crticas;
Uma infra-estrutura de rastreamento automatizado chamada
GCT, usada para ligar QAMs com metas, identificar pontos de
impacto, ligaes executveis entre QAMs e metas de forma a
suportar reavaliao durante uma anlise de impacto;
Algoritmos para controlar a propagao da mudana atravs da
hierarquia de metas, e que automatize a reavaliao das QAMs
para analisar impactos causados por mudanas;
Um relatrio de impactos que ir relatar os impactos potenciais
para mudanas nas metas de qualidade.
Na Figura abaixo, podemos observar uma viso geral do GCT como
explicado atravs das caractersticas citadas acima.
48
Figura 19.
19. Viso Geral do GCT (CLELAND-HUANG, 2008)
5.3 Mtodos de Avaliao de Qualidade QAMs

Mtodos de Avaliao de Qualidade so desenvolvidos para avaliarem metas
de qualidade, e incluem os seguintes tipos de modelos:
Modelos
executveis,
como
por
exemplo,
simulao
de
desempenho, que podem ser completamente automatizadas e

re-executadas durante todo o ciclo de desenvolvimento;
Modelos Avaliados Manualmente, podem ser utilizados durante a
anlise do impacto de uma mudana, pois prov informaes
importantes. Checklists para avaliar processos, e projeto e
codificao esto nesta categoria;
Modelos de Tempo de Execuo muito importante para
avaliao das metas de forma contnua e em tempo de execuo,
49
pois pode garantir que as metas de segurana esto sendo

cumpridas. Elas podem ser inicializadas de forma automtica a
cada intervalo de tempo, ou atravs de uma solicitao externa;
Casos de Teste podem ser escritos para verificar se uma
determinada funcionalidade foi implementada como especificado
na meta, e verifica tambm os impactos de uma mudana em
metas no-funcionais.
5.4 Modelagem de Metas

As metas so frequentemente modeladas em alto nvel, e depois so
refinadas em sub-metas mais especficas, solicitado pelos stakeholders.
Metas so modeladas cedo de forma que qualquer conflito ou
problema que venha a ocorrer com elas, possam ser resolvidos o quanto
antes. Algumas tcnicas de modelagem sero mostradas abaixo, e qualquer
uma delas pode ser usada com o GCT.
Framework NFR: A utilizao deste framework consiste em
identificar,
refinar,
relacionar
com
outros
requisitos
operacionalizar requisitos no-funcionais;

i*: I estrela uma abordagem orientada a agentes, em que os
atores so descritos como agente, e que podem representar suas
crenas,
metas,
habilidades
negociaes.
Agentes
heterogneos colaboram para executar metas relacionadas ou

opostas;
50
KAOS
(Aquisio
de
Conhecimento
em
Especificaes
Automatizadas: um mtodo formal para analisar metas e gerar

requisitos. Tanto requisitos funcionais quanto no-funcionais
podem ser representados atravs da modelagem KAOS.
rvores de Utilidade provm uma abordagem top-down para
transformar necessidades do negcio em cenrios concretos de
atributos de qualidade.
5.5 Avaliao de Metas

A avaliao de metas uma atividade crtica do GCT e envolve a construo
de uma funo F, que ir avaliar se as mudanas impactam nas metas
definidas. Esta avaliao pode ser automtica, parcialmente automtica e
totalmente manual, dependendo da meta e das ferramentas de suporte.
5.6 Ligando QAMs e Metas

As ligaes que conectam um QAM com uma meta devem ser capazes de
executar comandos que faam com que QAMs executveis sejam reavaliadas
sob demanda.
Um exemplo de como isto pode ser alcanado a atravs de um
ambiente centrado em processo (PCE) que prov a facilidade de modelar
processos e pode facilitar ligaes entre QAMs e Metas.
Ferramentas Industriais como a System Level Automation Tool for
Engineers (SLATE) prov mecanismos para gerenciar simulaes e capturar

dependncias entre simulaes e requisitos. Isso tambm pode ser usado
para programar mecanismos GCT.
51
5.7 Grafo Cruzado

Durante um impacto, a anlise indica os vrtices que foram impactados
chamando-os de pontos de impacto. Todos os vrtices que foram atingidos
so identificados e o grafo resultante cruzado e todas as metas visitadas
so avaliadas.
Na Figura 20, temos o algoritmo EVALUATE, que podemos explicar da
seguinte forma:
1. A entrada P do algoritmo o conjunto de pontos de impacto;
2. EVALUATE inicia nas linhas 2-17 marcando cada n com o valor
de filhos que foram potencialmente impactados e remove de P
qualquer n que foi atingido por outro ponto de impacto;
3. O loop principal de EVALUATE nas linhas 18-37, garante que
todos os ns filhos sero avaliados primeiro do que seus pais, e
que a informao mais atualizada utilizada na avaliao da
meta. Alm disso, nenhuma meta que no existam descendentes
no impactados, ou seja, que no podem ser afetados por uma
mudana, no so avaliadas nunca.
52
Figura 20.
20. Algoritmo EVALUATE (CLELAND-HUANG, 2008)
5.8 Condies de Guarda

De forma a no consumir tempo desnecessrio para realizar uma anlise
completa de metas, necessrio podar o grafo, de maneira que metas que
no sero impactadas por uma mudana saiam do mesmo.
Para isto uma guarda G adicionada a cada vrtice da hierarquia de
metas, e se este teste na guarda retornar TRUE, as variveis de sada dos
53
filhos so propagadas como entradas para os pais. Porm, se a guarda for

avaliado como FALSE, aquele caminho finalizado imediatamente.
5.9 Detectando Pontos de Impacto

Existem algumas tcnicas para deteco de pontos de impacto, como por
exemplo, monitoramento em tempo de execuo, reconstituio explicita e
automatizada, e anlise manual.
Monitoramento em Tempo de Execuo: Podem ser utilizadas
algumas QAMs para avaliar a conformidade do sistema com mas
metas dos stakeholders. Estas QAMs podem ser includas no
GCT, e caso tenha sido encontrado que no esto de acordo com
as metas, um ponto de impacto gerado.
Deteco de Rastro Automatizado: Modificaes de requisitos,
incluso de novos requisitos, projeto e implementao de um
software, tudo isso faz com que eventos de mudana possam
acontecer. No GCT possvel criar uma matriz de rastreamento,
em que possvel detectar pontos de impacto, porm, esta
matriz difcil de ser construda e mantida.
Pontos de Impacto Reconhecidos Manualmente: Caso no exista
nenhum
mecanismo
no
qual
seja
possvel
realizar
automaticamente, possvel realizar a deteco dos pontos de

impacto de forma manual, analisando e revisando a hierarquia
de metas. Porm, consome muito tempo e pode causar erros.
54
Depois de encontrar os pontos de impacto, necessrio iniciar a

anlise do evento, que pode ser feito atravs da re-execuo de modelos de
simulao de impacto, adicionando novas metas no modelo, utilizando
checklists, ou atualizando alguma varivel na meta. A funo de avaliao
deve ser computada novamente, e mais anlises iro acontecer caso a
condio de guarda seja computada como TRUE.
Relatrios de Impacto indicam um impacto negativo em metas de
usabilidade,
porm,
explicitamente,
caso
apenas
atravs
contrrio,
das
QAMs
impacto
possvel
mostrado
avaliar
apenas
qualitativamente, servindo como um demonstrativo de que mais anlises so

necessrias.
5.10 Um Exemplo de Segurana Crtica

Utilizaremos um dos estudos de caso que so apresentados em (CLELANDHUANG, 2008) para demonstrar a utilizao do GCT. Uma estao de fora
nuclear regulamentado de forma federal utilizada para treinar e certificar
operadores de estaes de fora.
O sistema tem muitas restries crticas e de tempo real, e deve prover
interface de hardware e software, bem como deve simular eventos de
impacto de forma a treinar os operadores para trabalharem com estas
situaes, deve ser possvel tambm, a reconfigurao para outros tipos de
estaes.
A modelagem em metas fez parte da atividade de desenvolvimento, e
sua
hierarquia
contem
metas
como
desempenho,
alta
fidelidade,
55
extensibilidade, escalabilidade, portabilidade, confiana, custo efetivo e a

efetividade do treinamento, e est mostrada na Figura 21, logo abaixo.
Figura 21.
21. Metas Primrias para o Simulador da Estao de Fora mostrando
QAMs para dois cenrios especficos de mudana. (CLELAND-HUANG, 2008)
Desempenho tinha sua dificuldade pois deveria realizar as mesmas
atividades no mesmo tempo da estao de fora real. Extensibilidade era
crtico na perspectiva de negcio, pois o projeto s seria lucrativo se pudesse
ser utilizado por uma variedade de estaes de foras, executando em
configuraes computacionais diferentes, interagir em mltiplas linguagens
de usurio e simular uma grande variedade de tipos de mecanismos.
56
Durante o teste de aceite de fbrica, os funcionrios podem escolher

aleatoriamente um interruptor ou uma lmpada e suas combinaes, e deve
poder utilizar um oscilatrio para poder avaliar a resposta do simulador. Se o
tempo de resposta diferir de mais de 200ms ou de 1% do valor especificado,
o teste de aceite ir falhar.
Devido a complexidade deste problema, ser focado apenas um
cenrio para demonstrar como o GCT foi aplicado para esta estao de fora.
As metas primrias esto na Figura 21, mostrada anteriormente e na Tabela
5 mostra as QAMs, para o cenrio a ser explicado, so descritas.
Tabela 5. QAMs do Simulador da Estao de Fora (CLELAND-HUANG, 2008)
Cenrio: Uma nova pea

pea de equipamento modelada e configurada
Neste cenrio, uma nova pea modelada e substituir uma j
existente, algo que acontece com freqncia, pois uma estao de fora est
sempre sendo aprimorada.
Ao desenvolver uma nova pea, o componente simulado primeiro
criado no modelador visual do simulador, isto lana uma QAM chamada Q-1,
mostrada na figura anterior, que havia sido estabelecida para monitorar o
tempo gasto para modelar um novo componente, e resultou num ponto de
57
impacto A. A meta para o sistema era que estes componentes pudessem ser
desenvolvidos em menos de 100 horas, e isto avaliado periodicamente pela
QAM Q-2.
Uma
vez
que
um
novo
componente
est
pronto,
deve
ser
reconfigurado dinamicamente por um engenheiro, e ento uma QAM Q-3

detecta a nova configurao e ento lana um evento do GCT com ponto
inicial de impacto B na meta nomeada como runtime configuration.
Os nomes dos componentes alterados so passados para as metas
Gauges respond < 200ms of physical plant e lights respond < 200ms of
physical plant. QAMs Q-4 e Q-5 so ento executados em todas as funes
identificadas que utilizam componentes trocados e compara o desempenho
com o que est especificado para os componentes fsicos. Sadas destes
testes so passadas como parmetros para a meta metrics within 1 percent
of real plant performance, em que a QAM Q-6 executada de forma a avaliar

se o desempenho est dentro da margem de 1% dos valores da estao real.
Se um ou outra meta de fidelidade falha em algum dos testes, o GCT
deve indicar o impacto sob as metas de fidelidade e desempenho.
58
6. Anlise das Abordagens de Rastreamento de Requisitos

Este Captulo apresenta uma anlise realizada, de forma suscinta e objetiva,
a cerca das trs abordagens estudadas neste trabalho, de acordo com a
forma que se segue:
Autores: Cysneiros & Zisman
Abordagem: Uma Abordagem Baseada em Regras para Gerao Automtica
de Relaes de Rastreamento entre modelos de projeto e especificaes de
cdigo em sistemas orientados a agentes.
Objetivos
Objetivos Principais: Suportar a
rastreamento
entre
modelos
de
gerao
projetos
automtica
modelados
de
na
relaes
de
ferramenta
Prometheus e especificao de cdigo implementado na ferramenta JACK,

ambos projetados para sistemas orientados a agentes; e Identificar os
elementos que estejam faltando nos modelos e na especificao dos cdigos
do projeto, de forma que garanta a completude de ambos.
Autores: Pinto et al.
Abordagem: Uma Abordagem para Apoiar o Rastreamento em Tropos.
Objetivos Principais: Armazenar informaes provenientes de todas as fases
apoiadas pela abordagem de Tropos, direcionando o rastreamento de
requisitos de forma a garantir uma melhoria da qualidade do software, uma
vez que todos os requisitos dos stakeholders esto direcionados, alm de
possibilitar uma anlise de impacto antes da implementao de algum
pedido de mudana.
59
Autores: Cleland-Huang et al.

Abordagem: Uma Abordagem de Rastreamento Centrado em Metas - Goal-
Centric Traceability (GCT) - Usando Virtual Plumbines.

Objetivos Principais:
Principais: Permitir, atravs de Virtual Plumbines, a escolha das
metas que se deseja monitorar, alm de suportar uma avaliao de metas
qualitativas e quantitativas, permitindo que os analistas criem modelos que
se adequem s necessidades crticas de projeto.
60
7. Concluses
O rastreamento de requisitos contribui provendo uma relao entre os
requisitos de um sistema, sua arquitetura e sua implementao. O objetivo
maior deste rastreamento prover informaes ao longo do tempo de quo
adequado est o sistema em relao ao que foi requisitado.
Esta verificao de aderncia qualidade esperada para o sistema, ir
contribuir para diminuio de tempo e custo de manuteno daquele
sistema.
As trs abordagens estudadas Cysneiros & Zisman, Pinto et al, e
Cleland-Huang et al. mostram como possvel utilizar o rastreamento de
requisitos para contribuir para o desenvolvimento de software, de forma que
seja possvel monitorar metas de qualidade deste sistema. Cada abordagem
tem seus objetivos e tipos de sistemas que se adquam melhor a esta
abordagem. Cada uma tambm ilustrada atravs de um estudo de caso de
forma a facilitar o entendimento dos que pretendem utilizar.
61
Referncias Bibliogrficas
(ALEXANDER, 2003) I.F. Alexander, Misuse Cases: Use Cases with Hostile
Intent IEEE Software, vol. 20, no. 1, pp. 58-66, Jan/Feb 2003.
(BERENBACH & SWANKE, 1984) B. Berenbach and J.E. Swanke, A Generic

Operation System Interface for VMS, Proc. Digital Equipment Corp. User Soc.,
pp. 661 - 662, Dec. 1984.
(BERENBACH et al., 1991) B. Berenbach, M. Koehler, and T. Novatin, The

Design and Implementation of an Object-Oriented Power Plant Training
Simulator, Simulators VIII, SCS Simulation Series, vol. 24, no. 1, Apr. 1991.
(BOEHM et al., 1973) B. Boehm, R. Brown, H. Kaspar, M. Lipow, G. McLeod,

and M. Merritt, Characteristics of Software Quality. TRW Series of Software
Technology, TRW Systems and Energy, Inc., also published by North Holland,
1978, 1973.
(CASTRO et al., 2002) J. Castro, M. Kolp, and J. Mylopoulos, Towards

Requirements-Driven Information Systems Engineering: The Tropos Project.
Information Systems Journal, Elsevier, 2002. Vol 27, pp. 365-89
62
(CLELAND-HUANG, 2005) J. Cleland-Huang, Toward Improved Traceability

of Non-Functional Requirements, Proc. Third Intl Workshop Traceability in
Emerging Forms of Software Eng., in conjunction with ASE 05, Nov. 2005.
(CLELAND-HUANG, 2008) J. Cleland-Huang, W. Matero, B. Berenbach, GoalCentric Traceability: Using Virtual Plumbines to Maintain Critical System
Qualities., IEEE Transactions on Software Engineering, Vol 34, N 35, 2008.
(CHUNG et al., 2000) L. K. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos,

Non-Functional Requirements in Software Engineering, Kluwer Publishing,
2000.
(CRONE, 2006) B. Crone, Getting It Done, SIM News, A Semi-Annual Report

on L-3 MAPPS Power Systems and Simulation Activities, no. 22, pp. 6-8, Feb.
2006.
(CYSNEIROS & ZISMAN, 2007) Cysneiros, C. and Zisman A., Traceability for
Agent-Oriented Design Models and Code, 19th International Conference on
Software Engineering and Knowledge Engineering (SEKE 2007), USA, July
2007.
(CYSNEIROS & ZISMAN, 2008) Cysneiros, C. and Zisman A., Traceability and
Completeness Checking for Agent-Oriented Systems, ACM Symposium on
Applied Computing (SAC 2008), Fortaleza, Maro 2008.
63
(DAVIS, 1993) Davis, A. M., "Software Requirements: Objects, Functions and

States". Englewood Cliffs, New Jersey: Prentice Hall. 1993.
(EDWARDS & HOWELL, 1991) Edwards, M. and Howell, S., "A Methodology for
System Requirements Specification and Traceability for Large Real-Time
Complex Systems", technical report, U.S. Naval Surface Warfare CenterDahlgren Division, Dahlgren, Va., 1991.
(GREENSPAN
&
McGOWAN,
1978)
Greenspan,
S.
and
McGowan,
C.,
"Structuring Software Development for Reliability," Microelectronics and

Reliability, vol. 17, 1978.
(HAMILTON & BEEBY, 1991) Hamilton, V.L. and Beeby, M.L., "Issues of
Traceability in Integrating Tools". In: IEEE Colloquium Tools and Techniques
for Maintaining Traceability during Design, 1991. Proceedings.
(JAIN, 1991) R. Jain, The Art of Computer Systems Performance Analysis:

Techniques
for
Experimental
Design,
Measurement,
Simulation,
and
Modeling. Wiley-Interscience, Apr. 1991.
(LUCK, 1999) Luck, M., From Definition to Deployment: What Next for
Agent-based Systems?, The Knowledge Engineering Review, Vol. 14:2,
pp.119-124, 1999.
64
(MARQUIONI, 2004) Marquioni, E.,
Os processos tpicos da engenharia de
requisitos
So
parte
5,
Paulo,2004.
Disponvel
em
http://www.choose.com.br/infocho ose/artigos/45art03.htm. Acesso em 3

de julho de 2009.
(PALMER, 1997) Palmer, J.D., "Traceability". In: Software Requirements Eng.,

R.H. Thayer and M. Dorfman, eds., pp. 364-374, 1997.
(PADGHAM & WINIKOFF, 2004) Padgham, L. and Winikoff, W., "Developing

Intelligent Agent SystemsA Practical Guide, John Wiley & Sons, 2004.
(PARR, 2007) Parr, T., The Definitive ANTLR Reference. Building Domain
Specific Language. The Pragmatic Programmers, LLC, 2007.
(PINTO et al., 2004) R. Pinto, A. Castor, C. Silva and J. Castro, Towards

Requirement Traceability in TROPOS, Anais do WER04 - Workshop em
Engenharia de Requisitos, Tandil, Argentina, pp 189-200, Dezembro 9-10,
2004.
(PINTO,
2008)
R.
Pinto,
Improving
Traceability
in
Agent
Oriented
Development. Ph.D thesis, Centro de Informtica da Universidade Federal de

Pernambuco UFPE, Brazil, March, 2008.
65
(POHL, 1996) Pohl, K., "Process-Centered Requirements Engineering," John

Wiley & Sons, 1996.
(RAMESH & JARK, 2001) Ramesh, B. and Jarke, M., "Towards Reference Models
for Requirements Traceability", IEEE Transactions on Software Engineering,
vol. 37, 2001.
(ROBERTSON & ROBERTSON, 1999) S. Robertson and J. Robertson, Mastering

the Requirements Process. Addison-Wesley, 1999.
(SEFFAH, 2001) A. Seffah, N. Kececi, and M. Donyaee, QUIM: A Framework

for Quantifying Usability Metrics in Software Quality Models, Proc. Second
Asia-Pacific Conf. Quality Software, p. 0311, 2001.
(SHEYNER, 2002) O. Sheyner, J. Haines, S. Jha, R. Lippmann, and J.M. Wing,

Automated Generation and Analysis of Attack Graphs, Proc. IEEE Symp.
Security and Privacy, pp. 273-284, May 2002.
(SOMMERVILLE, 2003) Sommerville, I. Engenharia de Software. 6th Edio,

Addison Wesley, 2003.
(TORANZO, 2002) M. Toranzo, A Framework to Improve Requirements

Traceability (in Portuguese: Um Framework para Melhorar o Rastreamento de
66
Requisitos). Ph.D thesis, Centro de Informtica da Universidade Federal de

Pernambuco UFPE, Brazil, December, 2002.
(WINIKOFF, 2005) Winikoff, M., JackTM Intelligent Agents: An Industrial

Strength Platform, Multi-Agent Programming, 2005.
(WORDNET) WordNet. http://wordnet.princeton.edu/.
(XQuery, 2005) Sherba, S., "Towards Automating Traceability: An Incremental

and Scalable Approach," PhD thesis, Dep. of Computer Science, University of
Colorado, 2005.
67

Thaysa Paulo - Gerencia de Projetos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Thaysa Paulo - Gerencia de Projetos

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDADE FEDERAL DE PERNAMBUCO

PS-GRADUAO EM CINCIA DA COMPUTAO

Paulo Csar de Oliveira

Prof. Jaelson Freire Brelaz de Castro

Universidade Federal de Pernambuco

Este trabalho apresenta um estudo a cerca do estado da arte de diferentes

Rastreamento de Requisitos ................................................................ 11

Uma Abordagem Baseada em Regras para Gerao Automtica de

Relaes de Rastreamento em Sistemas Orientados a Agentes .................... 15

Uma Abordagem para Apoiar o Rastreamento em Tropos .................... 35

Rastreamento Centrado em Metas Usando Virtual Plumbines para Manter

a Qualidade de Sistemas Crticos ................................................................ 46

Anlise das Abordagens de Rastreamento de Requisitos...................... 59

Referncias Bibliogrficas ........................................................................... 62

Figura 1. Trajetria de um requisito ........................................................... 14

Tabela 1. Tipos de Rastreamento de Requisitos ......................................... 12

AOS - Agent Oriented System

Este Captulo apresenta a motivao, os objetivos

trabalho est organizado.

1.3 Organizao dos Captulos

Captulo 2 Neste Captulo apresentada uma breve descrio a cerca de

O rastreamento de requisitos pode ser definido como uma tcnica utilizada

Sommerville, existem muitas relaes entre requisitos em si e entre

Tabela 1. Tipos de Rastreamento de Requisitos

Link do requisito com uma descrio

requisitos que sejam, de alguma

subsistemas onde estes requisitos

Link do requisito com hardware ou

Link do requisito com as interfaces

usados na proviso dos requisitos.

De forma a facilitar o rastreamento de requisitos, normalmente so

onde a linha dependente da coluna e a coluna depende da linha. Trata-se,

Nesse exemplo acima, R1 dependente de R3 e R5; R2 dependente

Figura 1. Trajetria de um requisito

Na primeira parte temos o rastreamento forward-to (para frente), que

backward-to, que liga artefatos de desenho e implementao de volta a

3. Uma Abordagem Baseada em Regras para Gerao

abordagem de rastreamento de requisitos que apoiasse o desenvolvimento

orientado a agentes (CYSNEIROS & ZISMAN, 2007). Essa abordagem foi

3.1 O Modelo Prometheus

Na ferramenta Prometheus pode-se encontrar os seguintes conceitos:

Agente: Representa uma entidade autnoma em um ambiente;

Percepo: Representa os dados recebidos por um ambiente;

Ao: Representa como um agente afeta um ambiente;

Objetivo: descreve a meta de um agente a ser realizada, algumas

atividades que o mesmo pretende alcanar, ou um estado que deve ser

Base de Dados: representa a informao que um agente externo

precisa ter acesso ou representa o conhecimento do agente sobre o

Regra: Especifica alguma funcionalidade e agrupa um conjunto

relacionado de objetivos, percepes, aes e base de dados;

Plano: uma sequncia de aes que o agente pode realizar para

atingir seu objetivo;

Mensagem: Representa a comunicao entre os agentes;

encapsular percepes, base de dados, aes, mensagens, planos e

Nas Figuras 2 e 3 so mostrados os dois exemplos utilizados na

Manager, Credit Card e Security Manager. O agente Sales Assistant responde

book catalogue e requesting a purchased item para serem removidos do

Figura 2. Exemplo de um diagrama resumido do sistema de livraria (CYSNEIROS &

A Figura 3 mostra o diagrama resumido de agente, que representa em

Acompanhando a sequncia lgica desse diagrama, na presena da

Invalid Login Message lanada. Os outros elementos do diagrama esto

Figura 3. Exemplo de um diagrama resumido de agente da livraria

3.2 Codificao JACK