Thaysa Paulo- gerencia de Projetos

UNIVERSIDADE FEDERAL DE PERNAMBUCO

PS-GRADUAO EM CINCIA DA COMPUTAO

CENTRO DE INFORMTICA

RRRRASTREAMENTO DE ASTREAMENTO DE ASTREAMENTO DE ASTREAMENTO DE RRRREQUISITOSEQUISITOSEQUISITOSEQUISITOS

AutorAutorAutorAutor

Paulo Csar de Oliveira

Thaysa Suely Beltro Paiva

OrientadorOrientadorOrientadorOrientador

Prof. Jaelson Freire Brelaz de Castro

Recife, Recife, Recife, Recife, JulhoJulhoJulhoJulho 2020202000009999

Universidade Federal de Pernambuco Centro de Informtica

2

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.

3

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

4

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

5

ndice de Figuras

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

Figura 2.Figura 2.Figura 2.Figura 2. Exemplo de um diagrama resumido do sistema de livraria

(CYSNEIROS & ZISMAN, 2007). .................................................................... 19

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


Figura 4.Figura 4.Figura 4.Figura 4. Trecho da implementao do SecurityManager na linguagem JACK


Figura 5.Figura 5.Figura 5.Figura 5. Trecho da implementao do plano SignIn em JACK (CYSNEIROS &

ZISMAN, 2008). .......................................................................................... 22

Figura 6.Figura 6.Figura 6.Figura 6. Trecho da implementao do evento UserLogin em JACK


Figura 7.Figura 7.Figura 7.Figura 7. Trecho da implementao do evento LoginResponse em JACK


Figura 8. Figura 8. Figura 8. Figura 8. Trecho da implementao do evento LoginResponse em JACK


Figura 9.Figura 9.Figura 9.Figura 9. Viso da Abordagem Baseada em Regras (CYSNEIROS & ZISMAN,

2008). ....................................................................................................... 25

Figura 10.Figura 10.Figura 10.Figura 10. Modelo de Regra de Rastreamento (CYSNEIROS & ZISMAN, 2007).

................................................................................................................. 31

Figura 11.Figura 11.Figura 11.Figura 11. Exemplo da Regra de Rastreamento de uma Dependncia


Figura 12.Figura 12.Figura 12.Figura 12. Exemplo da Relao de Rastreamento. ....................................... 34

6

Figura 13Figura 13Figura 13Figura 13. Sub-modelo de Gerenciamento de Requisitos (PINTO et al., 2004)

................................................................................................................. 36

Figura 14.Figura 14.Figura 14.Figura 14. Sub-modelo de Projeto (PINTO et al., 2004) ............................... 37

Figura 15.Figura 15.Figura 15.Figura 15. Sub-modelo de Raciocnio (PINTO et al., 2004) .......................... 38

FigFigFigFigura 16.ura 16.ura 16.ura 16. Diagrama de Atores do Media Shop (PINTO et al., 2004) ............. 40

Figura 17.Figura 17.Figura 17.Figura 17. Diagrama de Raciocnio do Sistema (PINTO et al., 2004) ............. 43

Figura 18.Figura 18.Figura 18.Figura 18. Grafo NFR (PINTO et al., 2004) ................................................... 44

Figura 19.Figura 19.Figura 19.Figura 19. Viso Geral do GCT (CLELAND-HUANG, 2008) ............................ 49

Figura 20. Figura 20. Figura 20. Figura 20. Algoritmo EVALUATE (CLELAND-HUANG, 2008) ......................... 53

Figura 21.Figura 21.Figura 21.Figura 21. Metas Primrias para o Simulador da Estao de Fora mostrando

QAMs para dois cenrios especficos de mudana. (CLELAND-HUANG, 2008)

................................................................................................................. 56

7

ndice de Tabelas

Tabela Tabela Tabela Tabela 1.1.1.1. Tipos de Rastreamento de Requisitos ......................................... 12

Tabela Tabela Tabela Tabela 2.2.2.2. Matriz de Rastreabilidade ........................................................... 13

Tabela Tabela Tabela Tabela 3.3.3.3.Tipos de Relaes de Rastreamento (CYSNEIROS & ZISMAN, 2008).

................................................................................................................. 27

Tabela 4.Tabela 4.Tabela 4.Tabela 4. Matriz de Rastreabilidade entre Posies e Argumentos (PINTO et

al., 2004) ................................................................................................... 45

Tabela 5.Tabela 5.Tabela 5.Tabela 5. QAMs do Simulador da Estao de Fora (CLELAND-HUANG, 2008)

................................................................................................................. 57

8

Lista de Siglas

AOS AOS AOS AOS ---- Agent Oriented System

GCT GCT GCT GCT ---- Goal-Centric Traceability

IBS IBS IBS IBS ---- Ice Breaker System

NFR NFR NFR NFR ---- Non-Functional Requirements

PCE PCE PCE PCE ---- Process Centric Environment

QAM QAM QAM QAM ---- Quality Assurance Management

SLATE SLATE SLATE SLATE ---- System Level Automation Tool for Engineers

SPE SPE SPE SPE ---- Software Performance Execution

UML UML UML UML ---- Unified Modeling Language

XML XML XML XML ---- eXtensible Markup Language

9

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.

10

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.

11

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).

12

Tabela Tabela Tabela Tabela 1111. . . . Tipos de Rastreamento de Requisitos

Tipo de Rastreamento Descrio

Requisitos FontesFontesFontesFontes

Link do requisito s pessoas ou

documentos que especificaram o

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 importante se os

subsistemas estiverem sendo

desenvolvidos por 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,

13

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 Tabela Tabela Tabela 2222. . . . Matriz de Rastreabilidade

R1R1R1R1 R2R2R2R2 R3R3R3R3 R4R4R4R4 R5R5R5R5

R1R1R1R1 XXXX XXXX

R2R2R2R2 XXXX XXXX

R3R3R3R3 XXXX

R4R4R4R4

R5R5R5R5 XXXX XXXX

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.

14

Figura Figura Figura Figura 1111. . . . 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).

15

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

16

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.

17

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 a 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.

18

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.

19

Figura Figura Figura Figura 2222. . . . 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) e 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.

20

Figura Figura Figura Figura 3333. . . . 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

21

armazenar informaes e os planos dos agentes usados para alcanar os

objetivos.

A Figura 4 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.

22

Figura Figura Figura Figura 4444. . . . Trecho da implementao do SecurityManager na linguagem

JACK (CYSNEIROS & ZISMAN, 2007).

Figura Figura Figura Figura 5555. . . . Trecho da implementao do plano SignIn em JACK (CYSNEIROS &

ZISMAN, 2008).

23

Figura Figura Figura Figura 6666. . . . Trecho da implementao do evento UserLogin em JACK


Figura Figura Figura Figura 7777. . . . Trecho da implementao do evento LoginResponse em JACK


Figura Figura Figura Figura 8888. . . . Trecho da implementao do evento LoginResponse em JACK


24

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.

25

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 Figura Figura Figura 9999. . . . Viso da Abordagem Baseada em Regras (CYSNEIROS & ZISMAN,

2008).

26

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. O componente

Completeness Checking Management suporta a gerao de elementos

ausentes identificados e da correo de inconsistncias entre os modelos.

27

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 Tabela Tabela Tabela 3333....Tipos de Relaes de Rastreamento (CYSNEIROS & ZISMAN, 2008).

28

Os tipos de relaes de rastreabilidade identificados na abordagem de

Cysneiros e Zisman so os seguintes (CYSNEIROS & ZISMAN, 2007):

OverlapsOverlapsOverlapsOverlaps 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)Contributes (Contributed by)Contributes (Contributed by)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)Uses (Used by)Uses (Used by)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

29

Validade User em Prometheus. Este um exemplo de uma relao

secundria devido a existncia de uma relao de overlaps....

Creates (CreaCreates (CreaCreates (CreaCreates (Created by)ted by)ted by)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) Achieves (Achieves by) Achieves (Achieves by) 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)Depends on (Is Dependent)Depends on (Is Dependent)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

30

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.

31

Figura Figura Figura Figura 10101010. . . . Modelo de Regra de Rastreamento (CYSNEIROS & ZISMAN, 2007).

Logo abaixo seguem as partes da regra de rastreamento:

Parte 1: Parte 1: Parte 1: 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

32

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: Parte 2: Parte 2: 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.

33

Figura Figura Figura Figura 11111111. . . . 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).

34

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), e elementos

relacionados (element ).

Figura Figura Figura Figura 12121212. . . . Exemplo da Relao de Rastreamento.

35

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:

36

Sub-modelo Gerenciamento de Requisitos: Quando o

rastreamento bem implementado, o gerenciamento de

requisitos beneficiado, facilitando o entendimento, captura,

rastreamento, validao e verificao de requisitos, como

mostrado na Figura 13.

Figura Figura Figura Figura 13131313. . . . 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.

37

Figura Figura Figura Figura 14141414. . . . 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.

38

Figura Figura Figura Figura 15151515. . . . 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;

39

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.

40

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 Figura Figura Figura 16161616. . . . 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

41

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.

42

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.

43

Figura Figura Figura Figura 17171717. . . . Diagrama de Raciocnio do Sistema (PINTO et al., 2004)

44

Figura Figura Figura Figura 18181818. . . . 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

45

baseado em estilos arquiteturais tradicionais devero ser armazenadas no

elemento ASSUMPTION. Na Tabela abaixo mostrado o relacionamento entre

elementos POSITION e ARGUMENT.

Tabela Tabela Tabela Tabela 4444. . . . Matriz de Rastreabilidade entre Posies e Argumentos (PINTO et

al., 2004)

46

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.

47

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

48

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.

49

Figura Figura Figura Figura 19191919. . . . 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,

50

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 e

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 e negociaes. Agentes

heterogneos colaboram para executar metas relacionadas ou

opostas;

51

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.

52

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.

53

Figura Figura Figura Figura 20202020. . . . 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

54

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.

55

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, apenas atravs das QAMs possvel avaliar

explicitamente, caso contrrio, o impacto mostrado 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 (CLELAND-

HUANG, 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,

56

extensibilidade, escalabilidade, portabilidade, confiana, custo efetivo e a

efetividade do treinamento, e est mostrada na Figura 21, logo abaixo.

Figura Figura Figura Figura 21212121. . . . 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.

57

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 Tabela Tabela Tabela 5555. . . . QAMs do Simulador da Estao de Fora (CLELAND-HUANG, 2008)

Cenrio: Uma nova pCenrio: Uma nova pCenrio: Uma nova pCenrio: Uma nova peaeaeaea de equipamento modelada e configuradade equipamento modelada e configuradade equipamento modelada e configuradade 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

58

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.

59

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:Autores:Autores:Autores: Cysneiros & Zisman

Abordagem:Abordagem:Abordagem: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.

ObjeObjeObjeObjetivos Principais: tivos Principais: tivos Principais: tivos Principais: Suportar a gerao automtica de relaes de

rastreamento entre modelos de projetos modelados na 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: Autores: Autores: Autores: Pinto et al.

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

Objetivos Principais: Objetivos Principais: Objetivos Principais: 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.

60

Autores: Autores: Autores: Autores: Cleland-Huang et al.

Abordagem: Abordagem: Abordagem: Abordagem: Uma Abordagem de Rastreamento Centrado em Metas - Goal-

Centric Traceability (GCT) - Usando Virtual Plumbines.

Objetivos PrincObjetivos PrincObjetivos PrincObjetivos Principais: ipais: ipais: ipais: 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.

61

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.

62

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

63

(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, Goal-

Centric 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.

64

(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 Center-

Dahlgren 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.

65

(MARQUIONI, 2004) Marquioni, E., Os processos tpicos da engenharia de

requisitos - parte 5, So 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.

66

(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

67

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.

Documents

Thaysa Paulo- gerencia de Projetos