tese requisitos

8/8/2019 Tese requisitos

1/224

Luiz Marcio Cysneiros

Requisitos No Funcionais: Da Elicitao aoModelo Conceitual

Tese apresentada ao Departamento deInformtica da PUC/RJ como parte dos

requisitos para a obteno do ttulo de Doutorem Cincias da Computao.

Orientador: Julio Cesar Sampaio do Prado Leite

DEPARTAMENTO DE INFORMTICA

PONTIFCIA UNIVERSIDADE CATLICA DO RIO DE JANEIRO


2/224

Pg - 2

ndicendice........................................................................................................................................................2ndice de Figuras.................................................................................................................................41 - Introduo ........................................................................................................................................... 9

1.1 - Motivao.....................................................................................................................................91.2 - Viso Geral da Soluo Proposta............................................................................................... 121.3 - Contribuies .............................................................................................................................14

2 - Conceitos Bsicos .............................................................................................................................162.1 - Engenharia de Requisitos ...........................................................................................................162.2 - Requisitos No Funcionais.........................................................................................................182.3 - Requisitos Funcionais versus Requisitos No Funcionais..........................................................222.4 - Classificao de RNFs................................................................................................................232.5 - O Lxico Ampliado da Linguagem............................................................................................ 272.6 - Cenrios......................................................................................................................................31

2.6.1 - Construo de cenrios a partir do LAL do UdI ................................................................. 342.7 - Grafo de RNFs ...........................................................................................................................372.8 - Unified Modeling Language.......................................................................................................41

2.8.1 - Viso Esttica......................................................................................................................432.8.2 - Viso de Interao..............................................................................................................462.8.3 - Object Constraint Language (OCL) .................................................................................... 48

3 - Lidando com RNFs: da Elicitao ao Modelo Conceitual ................................................................514 - Estendendo o Lxico ampliado da Linguagem..................................................................................585 Desenvolvendo a Viso No Funcional............................................................................................69

5.1 - Introduzir RNFs no LAL............................................................................................................705.2 - Gerar Grafos de RNFs................................................................................................................72

5.2.1 - Alteraes no Grafo de RNF ............................................................................................... 725.2.2 - Construo do Grafo de RNFs ............................................................................................ 78

5.3 - Identificar interdependncias e Resolver Conflitos....................................................................835.3.1 Comparar Grafos de um Mesmo Tipo................................................................................... 855.3.2 - Avaliar Grafos de Tipos Possivelmente Conflitantes..........................................................86

5.3.3 - Comparao Por Pares de RNFs..........................................................................................875.3.4 - Resoluo de Conflitos........................................................................................................906 - Estendendo os modelos da viso funcional.......................................................................................92

6.1 - Extenso aos Cenrios................................................................................................................926.2 - Extenso ao Diagrama de Classes .............................................................................................. 946.3 - Extenso aos Diagramas de Seqncia e Colaborao...............................................................97

7 Integrando as Vises Funcionais e No Funcionais ....................................................................... 1007.1 - Integrando RNFs aos Cenrios.................................................................................................1007.2 - Integrando RNFs ao Diagrama de Classes ............................................................................... 1057.3 - Integrando RNFs aos Diagramas de Seqncia e Colaborao................................................111

8 Validao da Estratgia ..................................................................................................................1168.1 Sistema de Iluminao I..............................................................................................................122

8.1.1 - Desenvolvendo a Viso No Funcional.............................................................................123

8.1.2 - Integrando as Vises Funcional e No Funcional .............................................................1318.2 - Sistema de Iluminao II..........................................................................................................1448.2.1 - Integrando as Vises Funcional e No Funcional .............................................................145

8.3 - Sistema de Automao de Laboratrios de Anlises Clnicas..................................................1558.3.1 - Desenvolvendo a Viso No Funcional.............................................................................1568.3.2 - Integrando as Vises Funcional e No Funcional .............................................................160

8.4 Consolidando os Estudos de Caso........................................................................................... 1699 Concluso ....................................................................................................................................... 172

9.1 - Contribuies ...........................................................................................................................1779.2 - Trabalhos Futuros.....................................................................................................................181

10 Bibliografia...................................................................................................................................183Apndice A Estudo de Caso I............................................................................................................191

Grafos de RNF..................................................................................................................................191

Classes..............................................................................................................................................198Apndice B Estudo de Caso II...........................................................................................................202Classes..............................................................................................................................................202


3/224

Pg - 3

Diagramas de Colaborao...............................................................................................................206Diagramas de Seqncia...................................................................................................................207

Apndice C Estudo de Caso III ......................................................................................................... 208Grafos de RNF..................................................................................................................................208Classes..............................................................................................................................................215Diagramas de Seqncia e Colaborao Antes dos RNFs................................................................221

Diagramas de Seqncia e Colaborao Aps dos RNFs.................................................................223


4/224

Pg - 4

ndice de FigurasFigura 2.1 - Classificao de RNFs proposta por Mamani [Mamani99]..................................24Figura 2.2 - Classificao de RNFs segundo Sommerville [Sommerville 92].........................24Figura 2.3 - rvore de Caractersticas de Qualidade de Software (Boehm 76) .......................25

Figura 2.4 Uma Taxonomia para RNFs ................................................................................26Figura 2.5 - Exemplo do LAL de um Sistema de Controle de Luzes......................................28Figura 2.6 Processo de Construo do LAL...........................................................................30Figura 2.7 - Heursticas de representao de entradas de LAL (extradas de [Hadad 97]) ......30Figura 2.8 Diagrama Entidade-Relacionamento descrevendo cenrios ................................32Figura 2.9 - Esquema para descrio de cenrios (Extrada de [Leite 97])..............................33Figura 2.10 Exemplo da Linguagem de Descrio de Cenrios.............................................34Figura 2.11 Exemplo de Decomposio do Grafo de RNF ....................................................38Figura 2.12 Grafo de RNFs Decomposto At Suas Operacionalizaes................................39Figura 2.13 Exemplo de Grafo com Interdependncias .........................................................40Figura 2.14 Grafo de RNFs com interdependncias analisadas ............................................41Figura 2.15 Exemplo de um Diagrama de Classes em UML ................................................45

Figura 2.16 Exemplo de um Diagrama de Seqncia ............................................................47Figura 2.17 Diagrama de Colaboraes .................................................................................48Figura 3.1 SADT da estratgia proposta ...............................................................................52Figura 3.2 Detalhamento da Estratgia Proposta...................................................................53Figura 4.1 Incluindo um RNF Primrio em um Smbolo .......Erro! Indicador no definido.Figura 4.2 RNFs Primrios contidos na Base de Conhecimento..........................................61Figura 4.3 Influncias entre RNFs Contidas na Base de Conhecimento...............................62Figura 4.4 Entrada do LAL com RNFs Primrios Assinalados.............................................63Figura 4.5 Selecionando o RNF que Originou uma Noo ou Impacto................................64Figura 4.6 Exemplo de Entrada do Lxico com Identificao de RNF de Origem...............65Figura 4.7 Exemplo da Navegao Entre RNFs e suas Conseqncias ................................67Figura 5.1 Processo de Elicitao de RNFs...........................................................................69Figura 5.2 Exemplo de Grafo de RNFs com Identificador de Origem do RNF....................74Figura 5.3 Exemplo de Operacionalizaes Estticas e Dinmicas......................................76Figura 5.4 Raiz de um Grafo de RNF Elicitada com o Uso da Ferramenta OORNF...........80Figura 5.5 Exemplo da Construo do Grafo de RNFs .........................................................81Figura 5.6 Analisando as Conseqncias de um RNF...........................................................83Figura 5.7 Interdependncia Entre Grafos de Mesmo Tipo ..................................................85Figura 5.8 Exemplo de RNFs Tipicamente Conflitantes.......................................................86Figura 5.9 Grafo Antes de Comparao por Pares ................................................................88Figura 5.10 Segundo Grafo para Comparar...........................................................................89Figura 5.11 Grafo Resultante de Novas Decises de Desenho .............................................90Figura 6.1 Exemplo de Cenrio com a Representao do RNF de Origem.........................93Figura 6.2 Exemplo de um Classe Estereotipada para Representar um RNF........................94Figura 6.3 Exemplo da Representao de Atributos advindos de RNFs...............................95Figura 6.4 Exemplo de Condies de Exceo Representadas em Comentrios ...................97Figura 6.5 Exemplo de Extenso ao Diagrama de Seqncia para expressar RNFs.............98Figura 6.6 Exemplo da Extenso ao Diagrama de Colaborao para Representar RNFs ......99Figura 7.1 Integrao de RNFs Cenrios...........................................................................101Figura 7.2 Exemplo de Uso de Grafos de RNFs para Avaliar Cenrios .............................102Figura 7.3 Cenrio Elicitado na Viso Funcional................................................................103Figura 7.4 Grafo de RNF com Smbolo Presente no Cenrio em Avaliao ......................103Figura 7.5 - Exemplo da Aplicao da Heurstica de Integrao de RNF a Cenrios............104Figura 7.6 Integrao de RNFs ao Diagrama de Classes ....................................................105Figura 7.7 Classe Sala Extrada da Viso Funcional...........................................................107

Figura 7.8 Grafo de RNF Sendo Integrado Classe Sala ...................................................108Figura 7.9 Classe Lugar, Superclasse de Sala.....................................................................109Figura 7.10 Alteraes na Classe Lugar para Satisfazer um RNF ......................................110


5/224

Pg - 5

Figura 7.11 Alteraes na Classe Painel de Controle para Satisfazer o mesmo RNF.........110Figura 7.12 Processo de Integrao de RNFs aos Diagramas de Seqncia e Colaborao

.........................................................................................................................................112Figura 7.13 Diagrama de Colaborao antes da Integrao dos RNFs ...............................113Figura 7.14 Diagrama de Colaborao Exibindo as Alteraes Advindas de RNFs...........113Figura 7.15 Diagrama de Seqncia....................................................................................114Figura 7.16 Diagrama de Seqncia Exibindo as Alteraes Advindas de RNFs ..............115Figura 8.1 Grafo do RNF Usabilidade Aplicada a Controle de Grupo de Luz....................125Figura 8.2 Incio da Construo do Grafo para o RNF Seguro, Aplicado Sala................126Figura 8.3 Grafo Resultante ................................................................................................127Figura 8.4 Verso Final do Grafo do RNF Seguro Aplicado Sala....................................128Figura 8.5 Grafo com Interdependncia Negativa Identificada...........................................129Figura 8.6 Grafos Aps Resoluo de Conflitos .................................................................129Figura 8.7 Conflitos Identificados entre dois RNFs............................................................130Figura 8.8 Grafo Representando Nova Soluo de Desenho ..............................................131Figura 8.9 Analisando um Cenrio Contra Grafos de RNF.................................................132Figura 8.10 Cenrio Atualizado para Satisfazer a RNF ......................................................133

Figura 8.11 RNFs Sendo Integrado a um cenrio ...............................................................134Figura 8.12 Cenrio Resultante...........................................................................................134Figura 8.13 Diagrama de Classes Definido por Breitman [Breitman 00] ...........................136Figura 8.14 Diagrama de Classes Aps a Integrao..........................................................136Figura 8.15 Um dos Grafos de RNF Usado Quando Avaliando a Classe Sistema de Controle

.........................................................................................................................................137Figura 8.16 Classe Sistema de Controle Antes dos RNFs...................................................138Figura 8.17 Classe Grupo de Luzes do Teto Resultante da Satisfao do RNFSeguro

Aplicado ao Smbolo Sistema de Controle .....................................................................138Figura 8.18 Grafo de RNF Aplicvel Classe Grupo de Luzes do Teto ............................139Figura 8.19 Resultado Final da Classe Grupo de Luzes do Teto.........................................140Figura 8.20 Classe Sistema de Controle com RNFs............................................................141Figura 8.21 Grafo de RNF para Usabilidade Aplicada Painel de Controle......................141Figura 8.22 Detalhamento da Classe Linha de Status .........................................................142Figura 8.23 Grafo do RNF Seguro Aplicado a Sistema de Controle...................................143Figura 8.24 Classe Painel de Controle e suas Subclasses....................................................143Figura 8.25 Classe Painel de Controle Aps Integrao com RNFs ...................................144Figura 8.26 Diagrama de Classes Antes dos RNFs.............................................................146Figura 8.27 Diagrama de Classes com RNFs......................................................................146Figura 8.28 Conjunto de Grafos de RNF Usados para a Classe Painel de Controle...........147Figura 8.29 Detalhamento da Classe Painel de Controle ....................................................148Figura 8.30 Detalhamento da Classe Painel de Controle Administrador............................149Figura 8.31 Detalhamento da Nova Classe Painel de Controle de Sala ..............................149Figura 8.32 RNFs Aplicados a Corredor.............................................................................150Figura 8.33 RNFs Aplicados a Corredor.............................................................................150Figura 8.34 Classe Corredor Antes dos RNFs.....................................................................152Figura 8.35 Classe Corredor Aps RNFs............................................................................152Figura 8.36 Classe Lugar que Superclasse de Corredor...................................................153Figura 8.37 Princpio da Composio de um Grafo de RNF para Laudo............................157Figura 8.38 Refinamento do Grafo da Figura 8.37..............................................................158Figura 8.39 Grafo Resultante Depois de validao com Cliente.........................................159Figura 8.40 Diagrama de Classes Original do Sistema de Laboratrios .............................160Figura 8.41 Parte do Diagrama de Classes Aps a Aplicao da Estratgia.......................161Figura 8.42 Grafo de RNF Integrado Classe Resultados a Inspecionar ............................161Figura 8.43 Classe Resultado a Inspecionar Antes da Integrao.......................................162Figura 8.44 Classe Histrico de Inspeo Criada aps a Integrao das Vises.................162Figura 8.45 Classe Central Mdica aps Integrao com RNFs .........................................163Figura 8.46 Classe LIS Depois da Integrao com RNFs ...................................................163


6/224

Pg - 6

Figura 8.47 Classe Fila de Impresso Resultante da Integrao de RNFs ..........................164Figura 8.48 Diagrama de Seqncia para a Entrada de Resultados s com os Requisitos

Funcionais .......................................................................................................................165Figura 8.49 Classe Exames Admitidos com RNFs..............................................................166Figura 8.50 Diagrama de Seqncia para Entrada de Resultados com RNFs....................167Figura 8.51- Diagrama de Colaborao Original para Inspecionar Resultado.......................168Figura 8.52 Diagrama de Colaborao para Inspecionar Resultados com RNFs................168


7/224

Pg - 7

ResumoO desenvolvimento de sistemas de informaes complexos necessita que utilize-se

modelos conceituais que lidem com aspectos que vo alm de entidades e atividades.

Em particular, pesquisas recentes apontam que esses modelos conceituais necessitam

modelar metas de forma a capturar intenes que fundamentam situaes complexas

que ocorrem em uma empresa. Uma classe em particular dessas metas chamada de

requisitos no funcionais (RNF) que necessitam ser capturados e analisados desde os

primeiros momentos do desenvolvimento do software. Erros provocados por no se

lidar convenientemente, ou simplesmente no lidar com RNFs so apontados como

estando entre os mais caros e difceis de corrigir. Apesar disso poucas propostas

apresentam maneiras sistemticas de se lidar com os RNFs. Essa tese procura abordar

dois aspectos de como se lidar com RNFs que ainda no foram convenientemente

abordados na literatura: como elicitar RNFs e como integr-los aos modelos

conceituais. Para isso, propomos uma estratgia que trata da elicitao dos RNFs

ainda no incio do processo de desenvolvimento de software e de como integrar os

RNFs elicitados aos modelos conceituais. A tese foi validada atravs de trs estudos

de casos que apontam, como espervamos, que o uso desta estratgia pode levar a

ganhos na qualidade do modelo conceitual final bem como a um processo de

produo de software mais produtivo.


8/224

Pg - 8

Abstract

The development of complex information systems calls for conceptual models that

model aspects beyond entities and activities. In particular, recent research has pointed

out that conceptual models need to model goals, in order to capture the intentions

which underlie complex situations within an organizational context. One particular

class of goals is named non-functional requirements(NFR) which need to be

captured and analyzed from the very early phases of the software development

process. Errors caused by not conveniently dealing, not dealing at all with NFR are

among the most difficult and expensive to correct. In spite of that, a few proposal are

met on the literature to systematically deal with NFRs. This thesis broaches two

aspects on dealing with NFR that were not covered in the literature: how to elicit NFR

and how to integrate them to the conceptual models. To do that, we propose a strategy

that deals with NFR during the early phases of software development and integratethese NFR to conceptual models. The thesis was validated by three case studies. The

results of these case studies suggest, that the use of the proposed strategy can lead to a

final conceptual model with better quality as well as to a more productive software

development process.


9/224

Pg - 9

1 - Introduo

1.1 - MotivaoA crescente complexidade dos sistemas de software e o aumento da exigncia de

qualidade por parte dos clientes vm impulsionando o mercado a cada dia produzir

mais softwares que atendam, no somente as funcionalidades exigidas, mas tambm a

aspectos no funcionais exigidos pelos clientes tais como: custo, confiabilidade,

segurana, manutenabilidade, portabilidade, performance, rastreabilidade de

informaes entre outros. Estes aspectos no funcionais devem ser tratados como

requisitos no funcionais (RNF) do software. Devem ainda ser tratados desde o incio

do seu desenvolvimento [Chung 95] [Chung 00] [Cysneiros 97] estendendo este

tratamento por todo o ciclo de vida do software.

Requisitos no funcionais vm sendo citados em vrios processos de

desenvolvimento de software, dentre outras formas como restries e condies de

contorno, porm sempre de maneira quando muito secundria e altamente informal do

ponto de vista da elicitao de requisitos. Este tipo de tratamento faz com que, quando

tratados, este requisitos sejam freqentemente contraditrios, difceis de serem

considerados durante o desenvolvimento de software e difceis de serem validados. O

fato destes requisitos terem sido mal elicitados ou no elicitados tem causado uma

srie de histrias de insucessos, incluindo a desativao de sistemas pouco aps terem

sido implantados [Finkelstein 96][Lindstrom 93]. Estudos apontam estes requisitos

como estando entre os mais caros e difceis de corrigir [Brooks 87] [Davis 93]

[Cysneiros 99].

Por outro lado, requisitos no funcionais tm recebido muito pouca ateno na

literatura e so muito menos compreendidos do que os outros fatores menos crticos


10/224

Pg - 10

ao desenvolvimento de software [Chung 00]. A maior parte dos trabalhos que

abordam RNFs, o faz orientado ao produto, ou seja, se situa no campo da

quantificao do grau de conformidade de um software para com os RNFs a que ele

deveria satisfazer [Keller 90] [Boehm 76] [Boehm 78] [Basili 91] [Fentom 97] [Musa

87] [Lyu 96].

Poucos trabalhos propem um tratamento explcito para RNFs sob a tica do

processo de desenvolvimento de software. Os trabalhos que seguem esta tica

propem o desenvolvimento de tcnicas para justificar decises sobre a incluso ou

excluso de requisitos que se refletiro no desenho do software durante o

desenvolvimento deste. Ao contrrio da abordagem orientada a produto, preocupada

em medir quanto um software satisfaz a RNFs, este tipo de abordagem procura

racionalizar o processo de desenvolvimento de software em termos de RNFs.

Freqentemente, quando adicionamos um RNF a uma especificao de requisitos,

foramos tomadas de decises que podero afetar positiva ou negativamente outros

RNFs, efeito esse visualizado como interdependncias entre RNFs. Estas

interdependncias podem ser positivas ou negativas, ou seja, um RNF pode

influenciar positivamente outro RNF contribuindo assim para sua satisfao, bem

como pode influenciar negativamente, ou seja, contribuir para que um destes RNFs

no seja satisfeito ou satisfeito apenas parcialmente. Dentre os trabalhos existentes,

destacamos os seguintes:

Boehm [Boehm 96] monta uma base de conhecimento com RNFs priorizados pela

viso do cliente, mas que entretanto s trata RNFs primrios, ficando assim num

nvel de abstrao ainda muito alto para identificao de conflitos entre RNFs ou

com requisitos funcionais.


11/224

Pg - 11

Kirner [Kirner 96] descreve as propriedades de 6 RNFs no domnio de sistemas de

tempo real, performance, confiabilidade, seguro, segurana, manutenabilidade e

usabilidade. O trabalho de Kirner descreve como medir estes RNFs e prope

algumas heursticas de como tratar com estes requisitos durante o

desenvolvimento deste tipo de software.

O Framework proposto por Chung [Chung 93] [Chung 95] [Chung 00] a

abordagem mais completa at o momento e procura tratar de todos os tipos de

requisitos no funcionais desde as primeiras etapas do processo de

desenvolvimento de software. Apesar de ser um framework bastante completo e

eficaz para lidar com requisitos no funcionais durante a elicitao de requisitos,

este framework no favorece a integrao destes requisitos nas etapas seguintes do

desenvolvimento de software, ficando, assim, uma lacuna aberta para que

conflitos entre requisitos funcionais e no funcionais passem desapercebidos

durante o projeto do software. Neto [Neto 00] prope uma estratgia apoiada pela ferramenta OORNF para o

desenvolvimento de software, baseada no lxico ampliado da linguagem estendido

para tratar RNFs. A partir do lxico, so gerados os cenrios, cartes CRC e um

modelo conceitual orientado a objetos. Apesar desta proposta ter apresentado bons

resultados nos estudos de casos controlados a que foi submetida, por tratar de

RNFs apenas no Lxico Ampliado da Linguagem [Leite 93], ela no favorece o

tratamento de interdependncias entre RNFs. Outro problema que o tratamento

de RNFs at o desenho do software s efetivo se utilizarmos a estratgia de

derivao de cenrios proposta por Hadad [Hadad 97] e a estratgia de derivao

de cartes CRCs e diagramas de classes proposta por Leonardi [Leonardi 97].


12/224

Pg - 12

Da anlise da literatura existente possvel observar que o uso dos RNFs durante o

processo de desenvolvimento de software abordado apenas de forma parcial. Pode-

se ainda observar, que existe uma lacuna no que tange existncia de propostas que

apresentem uma estratgia para o uso de RNFs, no apenas nas primeiras etapas do

processo de desenvolvimento de software, mas tambm na integrao dos RNFs

elicitados com os modelos conceituais gerados, e na conseqente avaliao de

impactos resultantes no desenho do software.

Trabalhos apresentados por Cysneiros [Cysneiros 99, Cysneiros 01] enfatizam

premissas apresentadas por Chung [Chung 00] de que a falta de integrao dos RNFs

aos requisitos funcionais, e por conseqncia sua integrao aos modelos conceituais,

pode resultar em tempos maiores para se finalizar um software, assim como maiores

custos com manuteno.

1.2 - Viso Geral da Soluo Proposta

Apresentaremos nesta tese um processo para se lidar com requisitos no funcionais

desde as etapas iniciais do processo de desenvolvimento de software. A integrao

dos RNFs, elicitados durante as fases iniciais do desenvolvimento do software, com

os modelos conceituais gerados a partir dos requisitos funcionais dever permitir

obtermos um modelo conceitual que enfoque os requisitos funcionais e no funcionais

ao mesmo tempo, obtendo-se assim modelos mais completos e com os impactos da

satisfao dos requisitos no funcionais j analisados, resultando em uma melhoria da

qualidade final do produto sob a tica, tanto do cliente quanto do desenvolvedor, bem

como em um menor tempo de entrega de produtos e menores custos de manuteno.


13/224


14/224


15/224

Pg - 15

O captulo cinco mostrar as extenses propostas para o grafo de RNF, como obt-

los a partir dos RNFs representados no lxico e uma sistematizao de processo para

identificao de interdependncias.

No captulo seis abordaremos as necessrias extenses aos modelos conceituais

utilizados, neste caso, o modelo orientado a objetos sob a notao UML.

O captulo sete ir detalhar a estratgia proposta nesta tese para a integrao dos

RNFs aos modelos conceituais funcionais, obtendo assim modelo conceituais que

espelhem as necessidades funcionais e no funcionais.

No captulo oito apresentaremos os estudos de caso realizados.

Na concluso apresentaremos as principais contribuies advindas da tese e

discutiremos possveis trabalhos futuros.


16/224

Pg - 16

2 - Conceitos Bsicos

2.1 - Engenharia de Requisitos

A engenharia de requisitos procura sistematizar o processo de definio de

requisitos. Essa sistematizao necessria porque a complexidade dos sistemas exige

que se preste mais ateno ao correto entendimento do problema antes do

comprometimento de uma soluo. [Leite 94]. Uma boa definio para requisitos pode

ser encontrada em [Leite 94] e mostrada a seguir.

Requisitos: Condio necessria para a obteno de certo objetivo, ou para

o preenchimento de certo objetivo .

Pesquisas sobre a aquisio (elicitao) de requisitos so valorosas por duas

razes: primeiramente, da perspectiva da engenharia de software, a elicitao de

requisitos talvez a mais crucial parte do processo de desenvolvimento de software.

Estudos [Boehm 84] indicam que, quando s detectados depois do software

implementado, erros em requisitos de software so at 20 vezes mais caros de se

corrigir que qualquer outro tipo de erro. Alm disso, elicitao de requisitos no

atualmente muito bem apoiada por ferramentas de software.

Para a engenharia de requisitos fundamental que o engenheiro de software

delimite os contornos do macrosistema em que a definio de software ocorrer, ou

seja, delimitar o Universo de Informaes do sistema (UdI).

importante ressaltar que o UdI sempre existe. O UdI independe do modelo que

estamos utilizando. Mesmo que o macrosistema no esteja bem definido, sempre

podemos, e devemos, estabelecer os limites de nossa atuao. Quanto mais bem

delineado um UdI, maiores so as chances de um software bem definido.


17/224

Pg - 17

A elicitao de requisitos um processo que est constantemente em evoluo, ou

seja, toda vez que o UdI muda, o modelo resultante do processo de elicitao de

requisitos deve mudar junto. Esta realidade muitas vezes desconsiderada atravs do

que se procurou determinar como um congelamento dos requisitos. Se por um lado a

constante evoluo do UdI pode gerar custos altos no desenvolvimento, uma vez que

temos de estar atualizando nossos requisitos, por outro lado o congelamento dos

requisitos em um determinado momento no deve produzir efeitos contrrios,

aumentando consideravelmente o custo do produto final em decorrncia de alteraes

que sero demandadas para a aceitao do software. Este um tema ainda pouco

explorado e maiores pesquisas devero ser realizadas neste campo para que possamos

conhecer o ponto ideal de equilbrio.

Em muitas organizaes, os requisitos so escritos como pargrafos em linguagem

natural e suplementados por diagramas [Kotonya98][Sommerville98]. A linguagem

natural a nica notao que compreendida por todos os leitores potenciais (ex.

clientes, usurios, engenheiros de software, engenheiros de requisitos) dos requisitos.

No obstante, alguns pesquisadores no compartilham desta viso tendo feito pesadas

crticas a esta utilizao e ressaltando a ambigidade como um dos problemas

inerentes aos requisitos escritos em linguagem natural [Meyer85]. Para ns, os

eventuais problemas que advm do emprego da linguagem natural so

fundamentalmente resultantes da m utilizao desta linguagem, e no

necessariamente problemas inerentes linguagem natural. Sommerville e Sawyer

apresentem cinco orientaes para se escrever requisitos em linguagem natural

[Sommerville98]. Toro apresenta padres lingsticos e padres de requisitos para

representar requisitos em linguagem natural [Toro99]. Leite apresenta uma estratgia

de representao de requisitos na qual utiliza listas de requisitos em linguagem


18/224

Pg - 18

natural, suplementadas por lxicos ampliados da linguagem do UdI [Leite92]. Estas

propostas podem minimizar os problemas identificados pelos crticos da linguagem

natural.

interessante ressaltar que diversos pesquisadores que apontavam a inerncia da

ambigidade da linguagem natural, recentemente mudaram de opinio. Kotonya

[Kotonya 95] afirma que alguns problemas devem ser tratados por todo mtodo da

engenharia de requisitos. Entre estes problemas, encontra-se a inerncia de

ambigidade da linguagem natural que poderia ocasionar ms interpretaes .

Posteriormente, Kotonya indicou que requisitos devem ser escritos em linguagem

natural e suplementados por diagramas [Kotonya98].

Uma vez que dificilmente teremos disposio recursos que permitam satisfazer

todos os requisitos dos usurios [Berry98], requisitos podem ser classificados como

desejveis ou obrigatrios, utilizando-se aqui de um enfoque voltado para a

necessidade de priorizar requisitos. Os requisitos podem ser ainda classificados como

estveis, mudam mais lentamente, ou volteis, mudam mais rapidamente. Esta

classificao auxilia a atividade de gerncia de requisitos, uma vez que possibilita

antecipar mudanas provveis de requisitos. Por fim, uma outra classificao que tem

tido bastante aceitao na comunidade acadmica [Yeh84] [Roman85] [Brackett90]

[Mylopoulos 92] [Sommerville98] [Kotonya98] [Mamani99] [Cysneiros99], divide osrequisitos em requisitos funcionais e requisitos no funcionais.

2.2 - Requisitos No Funcionais

A complexidade de um software determinada em parte por sua

funcionalidade, ou seja, o que o sistema faz, e em parte por requisitos gerais que

fazem parte do desenvolvimento do software como custo, performance,


19/224

Pg - 19

confiabilidade, manutenabilidade, portabilidade, custos operacionais entre outros

[Chung 00]. Estes requisitos podem ser chamados de requisitos no funcionais. Esta

denominao foi utilizada por Roman [Roman 85], sendo os RNFs tambm

conhecidos como atributos de qualidade [Boehm 78] [Keller 90], restries [Roman

85], objetivos [Mostow 85] entre outros. Recentemente, o termo requisitos no

funcionais vem se firmando como nomenclatura corrente no meio acadmico, sendo

esta a nomenclatura que iremos utilizar.

Os RNFs desempenham um papel crtico durante o desenvolvimento de

sistemas, e erros devido a no elicitao ou a elicitao incorreta destes esto entre os

mais caros e difceis de corrigir, uma vez que um sistema tenha sido implementado

[Brooks 87] [Davis 93].

Embora sem formalmente definir RNFs, alguns trabalhos propem

classificaes destes. Em um relatrio do Rome Air Development Center [Bowen 85],

RNFs so classificados da seguinte maneira:

orientados ao consumidor (ou critrios de qualidade de software), aqui se referindo

a requisitos observveis pelo cliente como eficincia, correo, amigabilidade e

outros; e,

atributos orientados tecnicamente (ou critrios de qualidade) associados mais a

requisitos ligados ao sistema, como tratamento de erros e anomalias, completeza,

processamento veloz em pontos crticos de tempo real e outros.

Duas diferentes abordagens so utilizadas em tratamento sistemtico de RNFs.

Elas podem ser classificadas como orientada a produto e orientada a processo [Chung

93]. A primeira aborda RNFs de forma a classificar o quanto um sistema satisfaz os

RNFs que dele so requeridos. Por exemplo, medir a visibilidade de um software pode

incluir, entre outras coisas, a medio de quantos desvios (branches) existem em um


20/224

Pg - 20

software. Isto pode ser obtido utilizando-se um critrio como: No deve haver mais

do que X desvios por 1000 linhas de cdigo. Quase todos os trabalhos em RNF

utilizam esta abordagem, orientada a produto, a qual bem descrita por Keller [Keller

90].

Boehm [Boehm 78] mostra que a qualidade geral do produto final de um software

pode ser melhorada simplesmente tornando os desenvolvedores conscientes de que

critrios de qualidade deviam ser cumpridos. Tambm baseados em uma abordagem

quantitativa sob a tica da qualidade de software, Basili e Musa [Basili 91] propem

modelos e mtricas para o processo de engenharia de software de uma perspectiva

gerencial.

J a abordagem orientada a processo, que por ns utilizada nesta tese, advoga o

desenvolvimento de estratgias para justificar decises de desenhodurante o processo

de desenvolvimento de software . Ao contrrio da abordagem orientada a produto,

nesta abordagem procura-se racionalizar o processo de desenvolvimento propriamente

dito em termos de RNFs [Chung 00]. Freqentemente, quando adicionamos um RNF

a uma especificao de requisitos, foramos tomadas de decises que podero afetar

positiva ou negativamente outros RNFs, efeito esse visualizado como

interdependncias entre RNFs. Estas interdependncias podem ser positivas ou

negativas, ou seja, um RNF pode influenciar positivamente outro RNF contribuindo

assim para sua satisfao, bem como pode influenciar negativamente, ou seja,

contribuir para que um destes RNFs no seja satisfeito ou satisfeito apenas

parcialmente.

Utilizamos nesta tese a noo de que um RNF raramente pode ser considerado

totalmente satisfeito. Em conformidade com o que utilizado por Mylopoulos

[Mylopoulos 92], onde utilizado o termo satisfice ao invs de satisfy,


21/224

Pg - 21

adotaremos daqui por diante a idia de que um RNF quando dito satisfeito, no

necessariamente ter sido totalmente satisfeito, e sim, satisfeito dentro de limites

razoveis de serem utilizados.

Ortogonalmente, podemos classificar o tratamento dispensado a RNFs como

divididos em qualitativos e quantitativos. A maioria das abordagens orientada a

produto quantitativa, uma vez que elas propem mtodos quantitativos para medir o

quanto um software satisfaz um dado RNF. As abordagens orientadas a processo so,

por outro lado, inteiramente voltadas para o aspecto qualitativo, via de regra adotando

idias oriundas do raciocnio qualitativo [AI 84].

RNFs abordam importantes aspectos relacionados qualidade de softwares. Eles

so essenciais para que softwares sejam bem sucedidos. A no observncia de RNFs

pode resultar em: softwares com inconsistncia e de baixa qualidade; clientes e

desenvolvedores insatisfeitos; tempo e custo de desenvolvimento alm dos previstos

devido necessidade de se consertar softwares que no foram desenvolvidos sob a

tica da utilizao de RNFs.

RNFs so geralmente subjetivos, uma vez que podem ser vistos, interpretados e

conceituados de forma diferente por diferentes pessoas. verdade que os requisitos

funcionais tambm sofrem do problema de diferentes contedos advindos de

diferentes pontos de vista, porm, como os RNFs so por natureza mais abstratos e

uma vez que NFRs so comumente relacionados de maneira breve e vaga este

problema potencializado [Chung 00].

Alm disso, RNFs freqentemente interagem entre si, uma vez que a tentativa de

satisfazer um RNF pode prejudicar ou ajudar a satisfazer outros RNFs. Como vrios

RNFs possuem efeitos de natureza global nos softwares, uma soluo localizada pode

no ser adequada.


22/224

Pg - 22

Por todas estas razes, RNFs so difceis de se lidar e vitais de serem tratados para

que possamos obter softwares de qualidade.

2.3 - Requisitos Funcionais versus Requisitos NoFuncionais

Os requisitos funcionais so requisitos que expressam funes ou servios que um

software deve ou pode ser capaz de executar ou fornecer. As funes ou servios so,

em geral, processos que utilizam entradas para produzir sadas.

Os requisitos no funcionais (RNFs) so requisitos que declaram restries, ou

atributos de qualidade para um software e/ou para o processo de desenvolvimento

deste sistema. Segurana, preciso, usabilidade, performance e manutenabilidade so

exemplos de requisitos no funcionais.

A distino entre o que um requisito funcional e o que um no funcional nem

sempre clara. Parte da razo advm para o fato de que os RNFs esto sempre

relacionados a um requisito funcional [EAGLE 95] [Chung 00]. A Grosso modo,

partindo da definio acima podemos dizer que um requisito funcional expressa

algum tipo de transformao que tem lugar no software, enquanto um RNF expressa

como essa transformao ir se comportar ou que qualidades especficas ela dever

possuir.

Um exemplo de diferena entre requisito funcional e RNF pode ser visto a seguir.Suponhamos que estejamos no domnio de laboratrios de anlises clnicas: um

requisito funcional desse sistema poderia ser expresso da seguinte forma:

O sistema deve fornecer uma entrada de dados que possibilite a

designao de resultados a exames admitidos para um paciente por

tcnicos, supervisores e chefes.

Este mesmo requisito funcional poder ter associado a ele o seguinte RNF:


23/224

Pg - 23

Alguns exames devero ter tratamento especial para a entrada de

resultados. Para estes exames valores acima ou abaixo de pr-

determinados valores s podero ser digitados por chefes de seo.

importante ressaltar que esse ltimo pargrafo no exprime uma funo do

sistema, e sim, uma restrio a uma funo existente, entrar resultados de exames. O

que se v aqui que essa funcionalidade do sistema dever ser restrita de forma que,

quando utilizada por pessoas que no sejam chefes, ser restrita condio de que

essas pessoas estejam digitando um valor que se encontre dentro de limites pr-

estabelecidos.

visvel que este RNF ir demandar um processo de segurana no tratamento de

acesso a mdulos do software, bem mais complexo daquele que seria implantado se

apenas o requisito funcional tivesse sido especificado. A implementao de um

processo de acesso a mdulos, que critique no apenas a permisso de acesso ao se

entrar em um mdulo de software, mas tambm o contedo do que est sendo

digitado dentro do mdulo, consideravelmente mais complexa. A tardia ou no

elicitao deste requisito certamente implicaria num grande retrabalho.

2.4 - Classificao de RNFs

Algumas classificaes dos RNFs podem ser encontradas na literatura.

Mamani prope a classificao de RNFs apresentada na Figura 2.1 [Mamani 99]

enquanto a Figura 2.2 apresenta a classificao de RNFs proposta por Sommerville

[Sommerville 92] e a Figura 2.3 mostra uma classificao proposta por Boehm

[Boehm 76] na qual ele define uma rvore mnima de padres de qualidade que um

software deveria apresentar.


24/224

Pg - 24

Figura 2.1 - Classificao de RNFs proposta por Mamani

Figura 2.2 - Classificao de RNFs segundo Sommerville

Uma outra fonte que classifica alguns RNFs o padro internacional ISO 9126

[ISO9126]. Nesta norma so descritas seis caractersticas que definem a qualidade de

software: funcionalidade, confiabilidade, usabilidade, eficincia, manutenabilidade e

portabilidade. Se observarmos as diversas definies de RNF, facilmente iremos

considerar que estes requisitos de qualidade definidos na ISO 9126 so, em geral,

Qualidade

PrecisoSeguranaDesempenhoInteroperabilidadeUsabilidadeManutenibilidade

PortabilidadeConfiabilidade

Requisitos No Funcionais

Operao

ImplementaoInterface (Automao)EconmicosPoltico-Legal

SoftwareHardware

Comunicaes

AbrangnciaOcorrnciaDetalheRepasse de Informao

Requisitos No Funcionais

Requisitos No Requisitos No Funcionais Funcionais

Requisitos deProcesso

Requisitos deProcesso

Requisitos deProduto

Requisitos deProduto

RequisitosExternos

RequisitosExternos

Requisitos deEntrega

Requisitos deEntrega

Requisitos deUsabilidade

Requisitos deUsabilidade

Requisitos dePerformance

Requisitos dePerformance

Requisitos deConfiabilidadeRequisitos deConfiabilidade

Requisitos dePortabilidadeRequisitos dePortabilidade

Requisitos deImplementaoRequisitos de

ImplementaoRequisitos

PadresRequisitos

Padres

SpaceRequirements

SpaceRequirements

Requisitos deCusto

Requisitos deCusto

Requisitos deInteroperabilidade

Requisitos deInteroperabilidade

RequisitosLegais

RequisitosLegais

PerformanceRequirementsPerformanceRequirements


25/224

Pg - 25

RNFs. O item funcionalidade , porm, uma exceo que certamente no poder ser

enquadrado como RNF.

Figura 2.3 - rvore de Caractersticas de Qualidade de Software (Boehm 76)

Proporemos aqui uma taxonomia que classifica os RNFs em primrios e

especficos. RNFs primrios so aqueles mais abstratos que representam propriedades

como: Confiabilidade, Rastreabilidade, Preciso, Segurana. J os RNFs especficos

so decomposies que se seguem aos RNFs primrios e tendem a diminuir o nvel de

abstrao de um determinado RNF, e portanto, atingir um nvel de granularidade no

tratamento da informao mais detalhado.

Um exemplo desta classificao seria o RNF PrimrioConfiabilidade que pode ser

decomposto em validao, autorizao e entrega do software.

RNFs primrios podem ser decompostos em outros RNFs secundrios at que se

chegue ao que Chung [Chung 00] chama de operacionalizao dos RNFs. Uma

operacionalizao de um RNF uma ao ou informao que ir garantir a satisfao

do RNF. Por exemplo, no caso de um sistema de informao para laboratrios de

anlises clnicas, a entrega do laudo ao paciente possui um RNF deconfidencialidade

Utilidade geral Utilidade geral

Utilidade Utilidade

manutenabilidade manutenabilidade

Independente de Dispositivos Independente de Dispositivos

Auto- Contidos Auto-

Contidos

Preciso Preciso

Completeza Completeza Robustez / Integridade Robustez / Integridade

ConsistenciaConsistencia

Contabilizao Contabilizao Eficincia em dispositivos Eficincia em dispositivos

Acessibilidade Acessibilidade Communicatividade Communicatividade

Auto- descritivo Auto- descritivo

Estruturao Estruturao

Conciso Conciso Legibilidade Legibilidade

Expansibilidade Expansibilidade

Portabilidade Portabilidade

Efficiencia Eficincia

Engenharia Humana Engenharia Humana

Testabilidade Testabilidade

Compreensibilidade Compreensibilidade

Modificabilidade Modificabilidade

Compreensibilidade Confiabilidade


26/224

Pg - 26

que seria seu RNF primrio. Para que possamos detalhar o que isso implica, temos de

decompor este RNF em um RNF especfico desegurana operacional que por sua

vez poderia ser decomposto na operacionalizaosolicitar carteira de identidade . Ou

seja, para satisfazer o RNFconfidencialidade teramos de prever uma ao no

sistema, que garantisse que o funcionrio que entregou o laudo solicitou a carteira de

identidade ao paciente antes de entregar-lhe o laudo.

Figura 2.4 Uma Taxonomia para RNFs

RNFs Dinamicos

Tempo real Performance ** Restries de tempo

Outras Clareza da Informao Custo

Seguro Qualidade Restries Operacionais Restries Fsicas Fcil de achar onde est um erro Manutenabilidade ** Fcil de modificar Estve

Fcil de testar

Portabilidade ** Adaptabilidade Fcil de migrar por plataformas

Usabilidade ** Fcil de aprender Fcil de Usar (interface adequada)

Confiabilidade ** Equipamento/Informao dispnvel quando necessrio Integridade Maturidade

RNF Esttico

Numerica Preciso Informao correta sempre disponvel

Rastreabilidade

Confidencialidade Identidade confirmada Dados privados no espostos

Qualidade Validao

Confiabilidade Autoriazao Entrega Permisso para consultar/atualizar informao

Segurana Confidencialidade de dados

RNF Primrio RNF Especfico

** ISO 9126

Caminho feito por algo/algum Qual o estado no momento

Tipo de equipamento a ser utilizado Ordens de exibio especficas


27/224

Pg - 27

Ortogonalmente, separamos os RNFs em estticos e dinmicos. RNFs estticos so

aqueles que, quando presentes,normalmente requerem o uso de dadospara valid-

los como, por exemplo: segurana, preciso e rastreabilidade. RNFs dinmicos, por

outro lado, usualmente representam conceitos mais abstratos,que normalmente

envolvem aes ou critrios de qualidadecomo, por exemplo: Qualidade,

performance, manutenabilidade, restries operacionais. Alguns RNFs podem ser

tanto estticos quanto dinmicos dependendo do contexto do domnio que estejam

inseridos. A Figura 2-4 mostra um resumo desta taxonomia que tambm pode ser

utilizada como um checklist para a elicitao de RNFs.

A lista apresentada na figura acima no pretende ser completa, mas sim, um ponto

de partida para cada desenvolvedor desenvolver seu prprio conhecimento a respeito

de RNFs. Uma lista mais exaustiva de RNFs pode ser encontrada em [Chung 00].

2.5 - O Lxico Ampliado da Linguagem

O principal objetivo do Lxico Ampliado da Linguagem (LAL) registrar a

linguagem utilizada pelos atores do UdI, sem contudo se preocupar com a

funcionalidade [Franco92][Leite93]. O LAL do UdI composto por entradas, onde

cada entrada est associada a um smbolo (palavra ou frase) da linguagem do UdI.

Cada smbolo pode possuir sinnimos e descrito atravs de noes e impactos. As

noes descrevem o significado e as relaes fundamentais de existncia do smbolo

com outros smbolos (denotao). Os impactos descrevem os efeitos do uso ou

ocorrncia do smbolo no UdI ou os efeitos de outras ocorrncias de smbolos no UdI

sobre o smbolo (conotao). Dependendo do smbolo que descrevem, as entradas

podem ser classificadas como sujeito, verbo, objeto e estado (predicativo).

Ao se descrever entradas do LAL, deve-se obedecer aos princpios de vocabulrio

mnimo e de circularidade. O princpio de vocabulrio mnimo demanda que a


28/224

Pg - 28

utilizao de smbolos externos ao LAL do UdI seja minimizada ao mximo. O

princpio de circularidade implica na maximizao da utilizao de smbolos do LAL

do UdI na descrio de smbolos. Os smbolos do LAL, que aparecem na descrio de

smbolos, devem ser sublinhados. Como decorrncia do princpio de circularidade, a

forma natural de representao do LAL pela utilizao de uma estrutura de

hipertexto. As entradas do LAL so os ns do hipertexto, enquanto que os smbolos

que aparecem nas descries de smbolos, so os elos do hipertexto. A Figura 2-5

apresenta uma entrada do LAL para um sistema de controle automtico de luzes. As

palavras sublinhadas so elos para outros smbolos do LAL.

Figura 2.5 - Exemplo do LAL de um Sistema de Controle de Luzes


29/224

Pg - 29

O processo de construo do LAL do UdI [Neto 00] (figura 2.6) engloba as

seguintes atividades:

O primeiro passo no processo de construo do LAL consiste na

identificao dos smbolos. Para tal, devemos identificar as palavras ou

frases da linguagem praticada no UdI que paream ter um significado

especial no UdI. Em geral, estas palavras ou frases so utilizadas com

freqncia por atores do UdI ou outras fontes de informao. Palavras ou

frases que parecem sem sentido, ou fora de contexto, tm grande

probabilidade de serem smbolos do UdI. As tcnicas de elicitao mais

adequadas para esta atividade so a observao, leitura de documentos e

entrevista no estruturada. As heursticas de identificao se resumem a

procurar sujeitos, verbos, objetos e estados (predicativos) presentes em

frases que surgem no UdI e que possuem um significado especial no UdI.

Antes de utilizar as heursticas, deve-se separar os perodos compostos em

oraes simples, transportar oraes na voz passiva para a voz ativa e

transformar as formas substantivas de verbos para a forma verbal

correspondente. Observou-se que a transformao das formas substantivas

de verbos para formas verbais correspondentes extremamente importante

para que se possa utilizar as heursticas de construo de cenrios a partir

do LAL do UdI, propostas por Hadad [Hadad97].

O segundo passo deste processo consiste na classificao dos smbolos.

Neste passo devemos determinar se os smbolos so sujeitos, verbos,

objetos e estados (predicativos) de frases que surgem no UdI.


30/224

Pg - 30

Figura 2.6 Processo de Construo do LAL

Figura 2.7 - Heursticas de representao de entradas de LAL A ltima etapa do processo resume-se descrio dos smbolos. Para

realizarmos esta etapa temos de criar entradas do LAL referentes aos

smbolos identificados. Para criar uma entrada do LAL para um smbolo,

deve-se descrever noes e impactos, seguindo as heursticas de

Cada entrada tem zero ou mais sinnimos. Cada entrada tem uma ou mais noes. Cada entrada tem um ou mais impactos. Escreva noes e impactos usando frases simples, que expressam uma nica idia. A descrio de noes e impactos deve respeitar os princpios de circularidade e vocabulrio mnimo. Para uma entrada que descreve um smbolo classificado como sujeito:

As noes devem dizer quem o sujeito (pessoa ou coisa) do qual se diz alguma coisa;

Os impactos devem registar as atividades que o sujeito realiza; Os sinnimos devem conter termos que tenham o mesmo sentido do smbolo no UdI.

Para uma entrada que descreve um smbolo classificado como verbo: As noes devem descrever sucintamente a ao e dizer quem o sujeito (pessoa ou coisa) que realiza a ao,

quando a ao acontece e quais as informaes necessrias para realizar a ao; Os impactos devem registrar os procedimentos que fazem parte da ao, as condies/situaes decorrentes

da ao e outras aes que devero ocorrer; Os sinnimos devem registrar a forma substantivada, a voz passiva e a forma infinitiva do verbo.

Para uma entrada que descreve um smbolo classificado como objeto:

As noes devem definir o ser (pessoa ou coisa) que sofre aes; Os impactos devem descrever as aes que podem ser aplicadas ao objeto; Os sinnimos devem conter termos que tenham o mesmo sentido do smbolo no UdI.

novas noes/impactos

Identificarsmbolos

Classificarsmbolos

Descreversmbolos

UdI

Tcnicas deelicitao Heursticas deidentificao

smbolos

Classes de smbolos

Tcnicas de elicitao

Classificaode smbolos

novos smbolos

novas noes/impactos

Identificarsmbolos

Classificarsmbolos

Descreversmbolos

UdI

Tcnicas deelicitao Heursticas deidentificao

smbolos

Classes de smbolos

Tcnicas de elicitao

Classificaode smbolos

novos smbolos


31/224

Pg - 31

representao. Algumas destas heursticas de representao so mostradas

na figura 2.7. A utilizao destas heursticas deve ser observada ao se

construir o LAL, para que as heursticas de construo de cenrios a partir

do LAL, propostas por Hadad [Hadad97], possam ser utilizadas. Nesta

atividade, identificam-se os sinnimos dos smbolos descritos por entradas

do LAL. Eventualmente, so identificados novos smbolos nesta atividade,

bem como novas noes e impactos de outros smbolos. As entradas do

LAL assumem as mesmas classes - sujeito, verbo, objeto e estado

(predicativo) dos smbolos que descrevem.

Conforme mostrado na Figura 2.6, o processo de construo do LAL continuado

sendo retomado sempre que alteraes surgirem no UdI que tragam novos smbolos

para o domnio ou pela descoberta de novos smbolos durante a elicitao de um dado

smbolo (princpio da circularidade).

2.6 - CenriosCenrios so construdos de diversas formas na literatura, indo da forma narrativa

at a forma de prottipos escritos [Carrol 95] [Booch 91] [Jacobson 92] [Zorman

95] [Potts 94]. Nesta tese utilizaremos a abordagem proposta por Leite [Leite 97],

onde os pontos centrais desta proposta so [Breitman 98]:

Cenrios descrevem situaes que ocorrem no macrosistema e suasrelaes com o sistema;

Cenrios evoluem durante o processo de desenvolvimento de software; Cenrios esto naturalmente ligados ao Lxico ampliado da linguagem

(LAL do UdI); Cenrios so descritos em linguagem natural.

O modelo de cenrios visa representar aspectos comportamentais dos requisitos e

faz parte de uma proposta maior, o Requirements Baseline [Leite97][Leite95]. A


32/224

Pg - 32

Figura 2.8 mostra um diagrama de entidades e relacionamentos para a estrutura de

cenrios proposta por Leite [Leite97], enquanto a Figura 2.9 explica cada uma das

entidades do cenrio, mostradas na Figura 2.8, bem como a sintaxe2 utilizada para

descrever estas entidades.

Figura 2.8 Diagrama Entidade-Relacionamento Descrevendo Cenrios

O relacionamento "expresso atravs do" entre as entidades cenrio e episdio,

indica que um episdio pode ser expresso ou explicado atravs de um cenrio,

possibilitando a decomposio de cenrios em sub-cenrios. O atributo restrio

indica, via de regra, requisitos no funcionais que se referem s entidades contexto,

recurso e episdio do modelo ER. O atributo exceo indica falta ou mau

funcionamento de um recurso necessrio para se atingir o objetivo do cenrio e deve

ser representado por frases curtas ou pequenos pargrafos.

2 + indica composio. n{ x }m indica no mnimon e no mximom ocorrncias de x. ( ) indicaagrupamento. | indicaou. [ x ] indica que x opcional.

Cenrio

Contexto Episdio

Ator

Recurso

Objetivo

Restrio

Restrio

PossuiNPossui

N

111

1Satisfaz

Delimitadopor

1

1

Dispara1

N

Restrio Exceo

Possui1

Expresso atravs do

1

(0,1)N


33/224

Pg - 33

Figura 2.9 - Esquema para Descrio de CenriosA Figura 2.10 mostra um exemplo da linguagem de descrio de cenrios

utilizando a ferramenta OORNF para descrever um cenrio para a definio de um

esquema de luzes em um sistema para controle de iluminao ambiente. As palavras

que aparecem sublinhadas so smbolos do LAL utilizados para descrever o cenrio.

Ttulo:ttulo do cenrio, que serve tambm para identific-lo. Em caso de sub-cenrio, o ttulo o mesmodo episdio que o sub-cenrio explica, sem as restries e excees.

Sintaxe: frase | ( [ Ator | Recurso ] + verbo + predicado )

Objetivo:meta que o cenrio pretende atingir. O cenrio descreve o alcance de um objetivo.Sintaxe:[ sujeito ] + verbo + predicado

Contexto:localizao geogrfica/temporal e estado inicial do cenrioSintaxe:localizao + estado, onde

localizao nome,estado ( [ ator | recurso ] + verbo + predicado + 0{restries}n ) +

0{ ([ e | ou ]+ [ ator | recurso ] + verbo + predicado + 0{restries}n ) }n

Recursos:meios de suporte, dispositivos e outras entidades passivas utilizadas pelos atores do cenrioSintaxe:1{nome + restries}n , onde

restries ( Restrio:deve ter + 1{RNF especfico}n )

Atores:pessoas ou estruturas organizacionais que tem um papel no cenrioSintaxe:1{nome}n

Episdios:aes que detalham o cenrio e fornecem seu comportamentoSintaxe: episdios :: = < srie >

srie :: = < sentena > | < srie > < sentena >< sentena > :: = < sentena seqencial > | < sentena no seqencial > |

< sentena condicional > | < sentena optativa >< sentena seqencial> :: = < sentena no seqencial > :: = # < srie > #< sentena condicional > :: = Se < condio > , ento < sentena episdio >< sentena optativa > :: = [ < srie > ]< sentena episdio > :: = [ator | recurso] + verbo + predicado + restrio +0{exceo}n,

onde:restrio (Restrio: + 1{recurso }n + deve(m) ter

+ 1{RNF especfico}n+ , sendo a estratgia de satisfao +

estratgia de satisfao)


34/224

Pg - 34

Figura 2.10 Exemplo da Linguagem de Descrio de Cenrios

2.6.1 - Construo de cenrios a partir do LAL do UdI

Hadad prope uma estratgia baseada no uso do LAL para gerar cenrios

[Hadad97] [Hadad99]. Esta estratgia baseia-se em algumas heursticas para realizar

tal construo, descritas a seguir:

Passo 1: Identificar atores do UdI.

Identificar os smbolos do LAL do UdI classificados como sujeito. Estes smbolosrepresentam os atores do UdI, os quais so classificados em primrios (atores que

realizam aes diretas sobre o sistema) e secundrios (atores que recebem/fornecem

informaes para o sistema, mas no executam aes diretas sobre a aplicao).

Passo 2: Identificar cenrios candidatos.

Recuperar os impactos das entradas do LAL do UdI associadas aos atores do UdI,

os quais foram obtidos no passo 1. Eliminar os impactos repetidos. Os impactos


35/224

Pg - 35

resultantes so os ttulos dos cenrios candidatos. Primeiramente obtemos os

impactos das entradas do LAL do UdI associadas a atores principais e, em seguida,

o mesmo realizado para as entradas do LAL do UdI associadas aos atores

secundrios.

Passo 3: Descrever cenrios candidatos.

Para cada cenrio candidato identificado no passo anterior, faa:

Se o ttulo do cenrio candidato possui um smbolo do LAL do UdI

classificado como verbo, ento:

1. Recuperar a entrada do LAL do UdI referente ao smbolo

classificado como verbo.

2. Definir o objetivo do cenrio com base no seu ttulo e nas noes

da entrada recuperada.

3. Verificar se existe alguma ordem de precedncia entre o impacto

que originou o cenrio com os outros impactos. Caso exista, incluirno contexto o impacto que o precede como uma pr-condio.

4. A partir de cada impacto da entrada, definir os episdios do

cenrio. Os episdios podem ser reescritos, utilizando a sintaxe

para episdios, que permite expressar comportamento. O mesmo

no possvel nos impactos de entradas de LALs do UdI.

5. Identificar atores e recursos, os quais devem ser entradas do LAL

do UdI classificadas respectivamente como sujeito e objeto.

Se o ttulo do cenrio candidato no possui um smbolo do LAL do UdI

classificado como verbo, ento:

1. Identificar os smbolos do LAL do UdI presentes no ttulo do

cenrio candidato.


36/224

Pg - 36

2. Definir o objetivo do cenrio com base no seu ttulo.

3. Verificar se existe alguma relao de precedncia entre o impacto

que originou o cenrio com outros impactos. Caso exista, inclui-se

no contexto o impacto que o precede como pr-condio.

4. Definir os atores e recursos com base nos smbolos recuperados. Os

atores so entradas do LAL do UdI classificadas como sujeito. Os

recursos so entradas do LAL do UdI classificadas como objeto.

Neste caso, no se definem episdios a partir do LAL do UdI.

Passo 4: Completar os cenrios com informaes provenientes do UdI.

Consiste em buscar informaes adicionais, com os atores ou outras fontes de

informao do UdI, para completar partes de cenrios que no puderam ser

preenchidas com as informaes fornecidas pelo LAL do UdI. Em geral, este passo

se aplica mais diretamente aos cenrios para os quais no se definiram episdios.

Passo 5: Analisar cenrios.

Consiste em validar e verificar cenrios. Os cenrios so validados com os clientes a

fim de identificar erros, omisses e/ou ampliar informaes de episdios. Esta

ampliao de informaes de episdios engloba a substituio de um episdio por

vrios episdios no mesmo cenrio e a descrio de episdios atravs de sub-

cenrios. A tarefa de verificao de cenrios consiste em:

Unificar cenrios.Dois ou mais cenrios, que possuem os mesmos

episdios ou o mesmo objetivo e contexto, so agrupados em um

nico cenrio. Quando necessrio, utiliza-se a forma condicional

para descrever episdios diferentes.

Detectar sub-cenrios.Se, em cenrios provenientes de atores

principais, um conjunto de episdios corresponde a um cenrio


37/224

Pg - 37

proveniente de um ator secundrio, substituir aqueles episdios por

este cenrio.

2.7 - Grafo de RNFs

A elicitao de RNFs demanda o uso de uma notao para represent-los de alguma

forma para que a informao no se perca no tempo. Alm disso, esta notao deve de

alguma forma possibilitar que lidemos com os RNFs de uma maneira organizada e

que facilite a lidarmos com as interdependncias. Como propomos que os RNFs sejam

elicitados desde as primeiras etapas do processo de desenvolvimento de software,

necessitamos de uma maneira de representar estes RNFs.

Para representarmos os RNFs iremos utilizar o grafo de RNFs proposto por Chung

[Chung 95] [Chung 00] com pequenas modificaes que sero apresentadas no

captulo 4. Segundo o Framework apresentado por Chung, RNFs devem ser

representados comometas a serem satisfeitas. Cada meta ser decomposta em

subseqentes submetas at encontrarmos o que so chamadas de operacionalizaes.

Uma operacionalizao corresponde a aes ou atributos que claramente identifiquem

o que necessrio para satisfazer a meta principal.

Chung divide a decomposio dos RNFs em tipo e tpico. Na decomposio por

tipo so usados fundamentalmente os mtodos de decomposio existentes no

framework, que indicam quais so as decomposies possveis para um determinado

RNF. No caso do RNF Segurana, por exemplo, integridade, confidencialidade e

disponibilidade podem ser possveis decomposies desta meta. A Figura 2.11,

extrada de [Chung 00], mostra um exemplo da decomposio do RNFSegurana

aplicado conta corrente como parte de um estudo de caso de automao bancria.

Neste exemplo pode-se ver que O RNFSegurana quando analisado sob a tica de


38/224


39/224

Pg - 39

satisfazer ao RNFSegurana . O momento de parar a decomposio uma deciso

pessoal e no existem regras fixas que determinem um limite.

Figura 2.12 Grafo de RNFs Decomposto At Suas Operacionalizaes

importante observar que todas as trs submetas de Autorizar Acesso a

Informao da Conta esto ligadas por um arco. Isto denota que as trs so

contribuies do tipo E, ou seja, para que a submeta seja satisfeita todas as trs

submetas tero de ser satisfeitas.

Por sua vez, a submeta de Acesso de usurio Autenticado possui outras trs

submetas que so ligadas por um arco duplo que desta feita denota uma contribuio

do tipo OU, ou seja, se uma das trs submetas for satisfeita a submeta imediatamente

superior ser satisfeita.

Neste novo grafo aparece ainda um outro RNF Boa Performance que tambm

decomposto at acharmos as operacionalizaes:Usar formato descomprimido e Usar

indexao .


40/224

Pg - 40

Figura 2.13 Exemplo de Grafo com Interdependncias

Uma anlise mais detalhada deste grafo ir revelar algumas interdependncias

entre submetas, algumas positivas representadas com um sinal + e outras negativas,

representadas com o sinal -. A figura 2.13 mostra estas interdependncias. Nela,

podemos observar que a operacionalizaoValidar Acesso X regras de elegibilidade

contribui positivamente para a satisfao da submetaPreciso e negativamente para a

SubmetaTempo de Resposta das contas do RNF Boa Performance para contas

correntes. Podemos ainda observar um impacto negativo da operacionalizaoPede

Id. Adicional no RNF Amigvel ao Usurio no acesso a contas correntes. Esta

contribuio negativa representada como uma possvel futura contribuio negativa

e adveio da consulta a uma base de conhecimentos de interdependncias entre RNFs.


41/224

Pg - 41

Figura 2.14 Grafo de RNFs com Interdependncias AnalisadasUma vez que detectamos interdependncias negativas temos que lidar com os

conflitos que elas representam, ou seja, avaliar quais metas e submetas devero no

ser satisfeitas ou satisfeitas apenas parcialmente, ou ainda, se apesar das contribuies

negativas todas as metas e submetas podem ser mantidas. A Figura 2.14 mostra o

grafo acima aps o engenheiro de requisitos ter tomado as decises necessrias. Neste

grafo o smbolo representa que esta operacionalizao foi escolhidas para serem

implementadas enquanto o X, representa operacionalizaes que foram rejeitadas

devido a seus impactos negativos em outras metas de maior importncia relativa.

2.8 - Unified Modeling Language

Informal Legend Subm eta Satisfeita Submeta Negada


42/224

Pg - 42

A Unified Modeling Language (UML) uma linguagem de modelagem visual de

propsito geral que utilizada para especificar, visualizar, construir e documentar

artefatos de um software. Ela captura decises e conhecimentos sobre o software a ser

construdo. A UML para ser utilizada para compreender, desenhar, configurar,

manter e controlar informaes sobre o software sendo desenvolvido. Em momento

algum ela atrelada com algum mtodo de desenvolvimento, ciclos de vida de

sistema ou domnios especficos, e portanto, pretende suportar a maioria dos

processos de desenvolvimento de software orientados a objeto existentes [Rumbaugh

99].

Rumbaugh [Rumbaugh 99] divide a UML em reas que por sua vez contm

vises, onde uma viso um subconjunto de construtores da UML que representam

um aspecto de um sistema. A UML fica ento dividida em trs reas: estrutural,

comportamento dinmico e gerncia de modelos.

A classificao estrutural descreve coisas existentes nos sistemas e seus

relacionamentos com outras coisas. Classificadores incluem, entre outros, classes,

ator, componentes, interface, tipo de dado e ns, podendo ser encontrados nas vises:

esttica, casos de uso e de implementao.

A rea de comportamento dinmico descreve o comportamento de um sistema no

tempo. Comportamento pode ser descrito como uma srie de fotografias de mudanas

no desenho do sistema retirados da viso esttica. Esta rea inclui as vises: mquinas

de estado, atividade e interao.

A gerncia de modelos descreve a organizao dos modelos propriamente ditos

atravs de unidades hierrquicas. Um pacote uma unidade organizacional genrica

para modelos. Pacotes especiais incluem modelos e subsistemas. A viso de gerncia


43/224

Pg - 43

cruza as outras vises e organiza-as objetivando o trabalho de desenvolvimento e

controle de configurao.

Nesta tese estaremos especialmente voltados para as vises estticas e de interao.

2.8.1 - Viso Esttica

A viso esttica modela tanto conceitos pertinentes ao domnio da aplicao quanto

conceitos inventados como parte da soluo proposta para a implementao desta

aplicao [Rumbaugh 99]. Esta viso denominada de esttica por no refletir os

comportamentos dependentes de tempo do software, os quais so descritos em outrasvises. Os principais participantes desta viso esto agrupados no diagrama de classes

e so classes e seus relacionamentos, a saber: associao, generalizao e vrios

outros tipos de dependncia. A viso esttica mostrada atravs do diagrama de

classes.

Um diagrama de classes descreve os tipos de objetos de um sistema e vrios tiposde relacionamentos estticos que existem entre eles. Existem dois tipos de

relacionamentos que se destacam [Fowler 97]:

Associaes: um cliente pode alugar um certo nmero de vdeos;

Subtipos: Uma enfermeira um tipo de pessoa.

Diagramas de classe mostram tambm atributos e operaes de uma classe e as

restries que se aplicam a como os objetos so interligados.

Fowler [Fowler 97] destaca ainda que um diagrama de classes pode ser construdo

utilizando-se trs diferentes perspectivas:

1. Conceitual: representa basicamente conceitos do domnio em estudo e em

geral independente de linguagem ou arquitetura de implementao;


44/224

Pg - 44

2. Especificao: representa um modelo j preocupado com a implementao do

problema sob forma de um software, onde solues de desenho so

implementadas como, por exemplo, o uso de padres [Gamma 94];

3. Implementao: Aqui todos os detalhes de tratamento de classes so utilizados

e o desenho passa a ser fortemente dependente de software e arquitetura

utilizados.

Classes so descritas utilizando-se um retngulo com trs diferentes

compartimentos onde so mostrados respectivamente, o nome da classe, seus atributos

e as operaes desta classe. A representao de atributos e operaes comumente

suprimida das classes exceto em um nico diagrama.

Relacionamentos entre classes so representados como caminhos conectando duas

classes (ou uma classe consigo mesma). Os diferentes tipos de relacionamentos so

distinguidos pela textura da linha e adereos nos caminhos e terminaes destes

[Rumbaugh 99]. A Figura 2.15, extrada de [Fowler 97], mostra um exemplo onde

aparecem os diversos componentes do diagrama de classes. necessrio ressaltar que

o que aparece entre {} so restries impostas ao modelo, que podem obter a forma

tanto de uma expresso formal quanto de uma sentena em linguagem natural.


45/224

Pg - 45

Figura 2.15 Exemplo de um Diagrama de Classes em UMLPodemos ver no exemplo mostrado na figura 2.15 que o diagrama l mostrado

indica uma associao entre as classes pedido e cliente onde o lado da associao

referente ao cliente possui uma multiplicidade 1 e a de pedido uma multiplicidade *,

indicando que um pedido tem de vir de apenas um cliente, mas um cliente pode

realizar diversas ordens. As multiplicidades mais comuns so 1, *, 0..1 (podemos ter

zero ou um). Esta associao especificamente representada por uma seta que indica

a navegabilidade desta associao. Neste caso significaria que um pedido tem aresponsabilidade de dizer a quais clientes ele pertence, enquanto um cliente no tem a

capacidade de dizer quais pedidos possui.

Uma associao pode ainda ter um papel associado a ela, como por exemplo, a

classe empregado da Figura 2.15 que possui o papel de representante de vendas.

possvel ainda, verificar na Figura 2.15 que a classe cliente uma generalizao

das sub-classes cliente corporativo e pessoa fsica. Isto significa que as sub-classes


46/224

Pg - 46

iro herdar os atributos (nome e endereo) e operaes (taxaCredito()) contidos na

classe cliente, alm de ter os seus prprios atributos e operaes.

2.8.2 - Viso de IteraoEsta viso descreve seqncias de trocas de mensagens entre papis que espelham

o comportamento do software. Um classificador do papel uma descrio de um

objeto que desempenha uma atividade particular dentro de uma interao, que o

distingue de outros objetos da mesma classe [Rumbaugh 99]. Um classificador possui

identidade, estado, comportamento e relacionamentos. A UML define diversos tipos

de classificadores entre eles: classes, ator, componentes, interface, tipo de dado e ns.

A viso de interao mostrada atravs de dois diagramas que enfocam aspectos

diferentes: o diagrama de seqncias e o diagrama de colaboraes.

2.8.2.1 - O Diagrama de Seqncia

O diagrama de seqncia mostra um conjunto de mensagens dispostas de maneira

temporal, ou seja, seqencialmente no tempo. Cada classificador mostrado atravs

de uma linha da vida do objeto, a qual representada atravs de uma linha vertical.

Mensagens so mostradas como setas entre linhas da vida. Um diagrama pode mostrar

um cenrio, ou seja, a histria individual de uma transao.

Cada mensagem possui pelo menos um nome de mensagem, sendo possvel ainda

incluir-se argumentos e mensagens de controle. possvel ainda representar-se auto-

delegaes que so mensagens enviadas de um objeto para ele prprio [Fowler 97].

Existem dois tipos de controles pr-definidos para serem utilizados no diagrama de

seqncia,condio e marcador de iterao.


47/224

Pg - 47

Condio um controle utilizado para indicar que aquela mensagem s ser

enviada caso a condio expressa seja verdadeira, onde a condio estar especificada

entre colchetes.

Marcadores de iterao so controles que estabelecem que uma mensagem

enviada mais de uma vez, o que caracteristicamente ocorrer quando quisermos atuar

sobre uma coleo.

A Figura 2.16 mostra um exemplo de um diagrama de seqncia extrado de

[Fowler 97] onde podem ser vistos exemplos de condio e iterao.

Figura 2.16 Exemplo de um Diagrama de Seqncia

2.8.2.2 - Diagrama de Colaboraes

Em um diagrama de colaboraes, ilustrado na Figura 2.17, os objetos so

mostrados como cones. Da mesma forma que no diagrama de seqncia, as setas

Iterao


48/224

Pg - 48

indicam as mensagens que so trocadas dentro de um dado cenrio, sendo que no

presente caso, a seqncia indicada por meio da numerao das mensagens.

O uso da numerao, se por um lado dificulta a visualizao de seqncias, por

outro favorece que outros detalhes sejam mostrados mais facilmente devido a

liberdade de diagramao [Rumbaugh 99].

Vrios tipos de numerao podem ser utilizados, inclusive qualquer um que seja

criado por um desenvolvedor, contanto que a semntica da numerao utilizada fique

bem clara para todos os envolvidos no projeto.

Os controles de condio e iterao relatados na seo anterior so aplicveis

tambm no diagrama de colaboraes.

Figura 2.17 Diagrama de Colaboraes

2.8.3 - Object Constraint Language (OCL)

Modelos grficos, como o diagrama de classes, no so suficientes para se gerar

uma especificao precisa e no ambgua. Freqentemente necessitamos expressar

restries nestes modelos, as quais so em geral descritas pelo uso de linguagem


49/224

Pg - 49

natural. Tal prtica normalmente resulta em especificaes ambguas ou imprecisas

[Rational 97]. Para evitar isso, alguns autores sugerem o uso de linguagens formais, as

quais entretanto, no so fceis de serem usadas por pessoas que no tenham uma

slida formao matemtica.

A OCL surgiu da necessidade de preencher este espao, ou seja, termos uma

linguagem com vis formal que se mantm fcil de ler e escrever. A OCL foi

desenvolvida como uma linguagem de modelagem de negcios dentro da diviso de

seguros da IBM e tem suas razes no Syntropy [Rational 97].

A OCL no uma linguagem de programao, logo, no possvel criar

programas ou controle de fluxos utilizando-a.

A OCL uma linguagem tipada, logo toda expresso OCL tem um tipo, onde

todos os tipos utilizados dentro de uma expresso devem estar em conformidade uns

com os outros.

O uso da OCL recomendvel para os seguintes propsitos [Rational 97]:

Especificar invariantes em classes;

Especificar invariantes para esteretipos;

Descrever pr e ps operaes;

Como uma linguagem de navegao;

Para especificar restries em operaes.

Por padro, quando uma expresso OCL escrita utiliza-se a fonte courier e uma

palavra sublinhada antes de uma expresso OCL, determina o contexto desta

expresso. Por exemplo:


50/224

Pg - 50

PessoaSelf.age>0

No exemplo acima, a expresso OCL se d no contexto da classe de objetos Pessoae estabelece que a idade de uma pessoa tem de ser maior que zero. A utilizao do

Self indica que o atributo age pertence ao prprio contexto de pessoa e poderia ser

omitido.

O exemplo a seguir demonstra o uso de ps-condio dentro de um determinado

contexto:

Pessoa::Aniversrio{}

Post: idade = idade@pre + 1

No exemplo acima demonstrado que na ocorrncia da operao Aniversrio na

classe de objetos Pessoa garantido que ao final da execuo desta operao a

expresso que segue a clusula post ser verdadeira. No presente caso, a expresso

determina que o atributo idade terminar com o valor com o qual ele comea a

operao somado de um.

O uso da clusula pre: determina que para que aquela operao seja realizada

necessrio que a expresso seguinte clusula seja verdadeira. A execuo de uma

operao pode ser parte integrante de uma clusula post, significando que esta

operao ter de ser feita antes da operao determinada pelo contexto ser realizada.

Por exemplo:

Empresa:: contrataPessoa{p:pessoa}

Pre: p not empregado


51/224


52/224

Pg - 52

modelos. Em conseqncia, a construo tanto do grafo de RNFs (artefato usado para

representao dos RNFs), bem como do diagrama de classes (artefato usado para

representao num primeiro momento dos requisitos funcionais e posteriormente de

todos os requisitos) dever ser feita tomando-se o uso de smbolos do lxico como

restrio para a nomeao de tipos de RNFs no grafo e das classes no diagrama de

classes. Desta forma, uma entrada comum no lxico ir servir como ligao entre o

modelo no funcional e o funcional. Isto facilita a anlise de em que parte do modelo

conceitual um RNF ir impactar, ou seja, a correta ligao entre o modelo no

funcional e o funcional. A Figura 3.1 mostra um SADT que ilustra a estratgia como

um todo.

Figura 3.1 SADT da estratgia proposta

A estratgia proposta pode ser encarada como um meta-modelo que pode ser

instanciado para ser utilizado tanto com o modelo entidade-relacionamento quanto

com o modelo orientado a objetos. Nesta tese estaremos concentrados no

CONSTRUIR CONSTRUIR O O

LXICO LXICO

CONSTRUIRCONSTRUIRVISO VISO

FUNCIONAL FUNCIONAL

LAL

CONSTRUIR CONSTRUIR VISO VISO

NO-FUNCIO- NO-FUNCIO- NAL NAL

INTEGRAR VISES VISES

Grafo de RNFs

Modelo OO

Modelo OO-NFR

conflitos Novos Smbolos do LAL

Representao do LAL

Processo de elicitao do LAL

UdI Representao /OO

Processo deelicitao

Pprocesso de elicitao

dos RNFs

representao dos RNFs

Estratgia deIntegrao

Ferramenta OORNF

Ferramenta OORNF


53/224

Pg - 53

detalhamento da instanciao da estratgia para o modelo orientado a objetos. A

instanciao desta estratgia para o modelo entidade relacionamento

tese requisitos

Documents