· ii dados internacionais de catalogação-na-publicação (cip) biblioteca central do campus de...

LUCIANA DE PAIVA SILVA

A ENGENHARIA DE REQUISITOS ORIENTADA A ASPECTOS: A ABORDAGEM DAORE

MARINGÁ

2007

ii

Dados Internacionais de Catalogação-na-Publicação (CIP) Biblioteca Central do Campus de Cascavel - Unioeste

S581e

Silva, Luciana de Paiva

A engenharia de requisitos orientada a aspectos: a abordagem DAORE. / Luciana de Paiva Silva. — Maringá, PR: UEM, 2007.

233 f. ; 30 cm

Orientadora: Profa Dra. Tania F. Calvi Tait

Dissertação (Mestrado) – Universidade Estadual de Maringá. Programa de Pós- Graduação em Ciência da Computação.

Bibliografia.

1. Sistemas de informação. 2. Orientação a aspectos. 3. Engenharia

de requisitos. I. Tait, Tania F. Calvi. II. Universidade Estadual de Maringá. III. Título.

CDD 21ed. 005.1

CIP – NBR 12899 Ficha catalográfica elaborada por Jeanine Barros CRB-9/1362

iii

LUCIANA DE PAIVA SILVA

A ENGENHARIA DE REQUISITOS ORIENTADA A ASPECTOS: A ABORDAGEM DAORE

Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Estadual de Maringá, como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.

Orientadora: Profa. Dra. Tania Fatima Calvi Tait

MARINGÁ

2007

iv

Ao que foi e que sempre será meu apoio, meu amigo, meu cúmplice e meu marido: Sérgio.

v

AGRADECIMENTOS

“Nada é mais difícil, e por isso mais precioso, do que ser capaz de decidir.”

Napoleão

Apoiar do Latim Appodiare significa ajudar, confirmar, dar apoio, fundar-se..

Todas as conquistas são repletas de dificuldades e, para vencê-las, é necessário apoio em

todas as formas.

O apoio recebido ajuda no desenvolvimento de um projeto, seja ele pessoal ou comunitário.

As pessoas aqui listadas ofereceram um tipo de apoio, que é imprescindível a qualquer

projeto, a força que move montanhas... o apoio que vence barreiras de distâncias, de oceanos

e até mesmo espiritual.

Gostaria de agradecer a todos que de alguma forma me ajudaram a realizar este desafio. Sem

o apoio recebido jamais teria conseguido.

Muito obrigado:

· A Nossa Senhora, pela força espiritual que inspira, protege e ilumina constantemente a minha vida;

· Aos meus amados pais, Antonio e Francisca, por me tornarem quem eu sou, pelo amor, pela dedicação, por todos os sacrifícios para que eu chegasse até aqui, sacrificando sua antiga morada e seus amigos, no Rio de Janeiro, para uma cidade estranha, apenas para me ajudar e por terem sido fortes, mesmo quando a minha distância os fazia sofrer;

· Ao meu filho Thyago, por ser meu amigo e me incentivar no caminho do saber;

· A minha filha Julia, que com seu sorriso e seu jeitinho meigo de ser, me fizeram vivenciar momentos de alegrias durante minha jornada;

· Ao meu amigo, meu cúmplice e meu companheiro de sempre, Sergio, que com seu amor incondicional me impulsionaram a buscar mais uma realização, mais uma conquista, e por despertar em mim uma admiração crescente e constante;

· A minha avó Nina, seu apoio espiritual foi imprescindível para a realização dos meus sonhos;

· A minha amiga Aline, por ser minha irmã e minha companheira dos momentos felizes e infelizes em nossa estada em Maringá;

vi

· A minha orientadora Tânia, pelo incentivo, confiança e pela parceria nas idéias e discursões, alem de agüentar minhas reclamações;

· A professora Elisa, por ter me propiciado o primeiro contato com a orientação a aspectos e pelas importantes contribuições para o enriquecimento desta dissertação;

· Aos pesquisadores com os quais me correspondi, especialmente a Awais Rashid, Eric SK Yu, Marcio Cysneiros, Silvio Meira, Jaelson Castro, Julio Leite, Karin Breitman e John Mylopoulos;

· Ao prof. André Luiz de Medeiros Santos, meu orientador do doutorado, do Cin - UFPE, pela paciência e bom humor durante esta fase do mestrado;

· Ao Departamento de Informática da UEM, pelo suporte técnico e acadêmico durante minha estada; e

· A todos aqueles que torceram e acreditaram em mim e neste trabalho.

Agradecimentos

vii

“Há duas formas para viver sua vida: uma é acreditar que não existe milagre;

a outra é acreditar que todas as coisas são um milagre“. Albert Einstein

“Porque para Deus nada é impossível”. Lucas 1,37

viii

Resumo

SILVA, Luciana de Paiva. A Engenharia de Requisitos Orientada a Aspectos: A Abordagem DAORE. 233f. Dissertação (Mestrado em Ciência da Computação) – Programa de Pós- Graduação em Ciência da Computação, UEM,Maringá.

Ao desenvolvermos um projeto de sistemas de informação, geralmente não

modelamos os chamados crosscuting concerns, tendemos a modelar algumas características

isoladas e não realizamos a separação e composição destas características.

A orientação a aspectos permite a modelagem destas características nos projetos,

possibilitando a identificação de características comuns em várias partes do sistema.

Inicialmente voltada para a implementação e agora com várias pesquisas relacionadas às fases

iniciais do desenvolvimento do processo de software, a orientação a aspectos permite que se

obtenha muitas vezes os requisitos aspectuais, ou seja, os aspectos identificados nas fases

iniciais do processo de desenvolvimento, que são fatores importantes e imprescindíveis desde

o início do projeto de sistemas.

Assim, este projeto de dissertação insere-se num tema que tem recebido crescente

atenção no processo de desenvolvimento de sistemas: a aplicação da orientação a aspectos nas

fases iniciais do processo de desenvolvimento, ou como é conhecida na linguagem aspectos:

early aspects.

Este trabalho realiza um estudo e análise de algumas das abordagens existentes na fase

de engenharia de requisitos por meio da introdução de uma nova abordagem, denominada

DAORE – Distributed Aspect Oriented Approach for Requirements Engineering, como

solução para aplicação do LEL – Léxico Extendido da Linguagem e da metodologia MDSODI

- Methodology for Development of Distributed Software, permitindo a definição destes

conceitos nos projetos e requisitos elucidados a serem desenvolvidos no projeto DiSEN -

Distributed Software Engineering Environment e em outros projetos a serem desenvolvidos

utilizando esta metodologia.

Para avaliar nossa abordagem aplicamo-la em um sistema de controle de eventos.

ix

Abstract

SILVA, Luciana de Paiva. A Engenharia de Requisitos Orientada a Aspectos: A Abordagem DAORE. 233f. Dissertação (Mestrado em Ciência da Computação) – Programa de Pós- Graduação em Ciência da Computação, UEM, Maringá.

When we develop a information systems project, generally we do not shape the calls

crosscutting concerns, we tend shape it some isolated characteristics and we do not carry

through the separation and composition of these characteristics.

The aspects oriented approach allows the modeling of these characteristics in the

projects, allowing to identify common characteristics in some parts of the system are

identified. Initially come back toward the implementation and now with some related research

the initial phases of the project, the orientation the aspects allows that if it gets many times the

aspects, that they are important and essential factors since the beginning of the project of

systems.

Thus, this project is inserted in a subject that has received increasing attention in the

process from development of systems: the application of the aspects oriented in the initial

phases of the development process, or as it is known in the language aspects: early aspects.

The considered work search to carry through a study and analysis of the existing

approaches in the phase of the requirements engineering by means of the introduction of a

new approach, called DAORE - Distributed Aspect Oriented Approach for Requirements

Engineering, as solution for application of the LEL – Language Extended Lexicon and the

methodology MDSODI - Methodology for Development of Distributed Software, allowing to

the definition of these concepts in the projects and elucidated requirements to be developed in

the project DiSEN - Distributed Software Engineering Environment and in other projects to

be developed using this methodology.

To evaluate the use of our approach, we apply it in the context of an events manager

system.

x

Lista de Abreviaturas

AOD Aspect Oriented Development AORE Aspects Oriented Requirement Engineering DiSEN Distributed Software Engineering Environment DAORE Distributed Aspect Oriented Approach for Requirements Engineering I* Distributed Intentionality LAL Léxico Ampliado da Linguagem LEL Language Extended Lexicon ou Léxico Extendido da Linguagem MDSODI Methodology for Development of Distributed Software NFR Non-functional Requirements POA Programação orientada a aspectos POO Programação orientada a objetos UML Unified Modeling Language RE Engenharia de Requisitos RF Requisitos Funcionais RNF Requisitos não-funcionais RO Requisitos organizacionais XML Extensible Markup Language

xi

Lista de Figuras

CAPÍTULO 1 FIGURA 1.1 ESTRUTURA DA PESQUISA A SER SEGUIDA.......................................... 9 CAPÍTULO 2 FIGURA 2.1 MODELO DE SEPARAÇÃO AVANÇADA DE CONCERNS......................... 18 FIGURA 2.2 PROCESSO DE COMBINAÇÃO DE ASPECTOS E CLASSES PARA GERAR O

SISTEMA............................................................................................. 23

FIGURA 2.3 ESTRUTURA DE UMA ENTIDADE ASPECT EM ASPECTJ....................... 25 FIGURA 2.4 EXEMPLO DE CÓDIGO EM ASPECTJ.................................................... 25 FIGURA 2.5 MODELO DE PROCESSO AORE........................................................... 27 FIGURA 2.6 EXEMPLO DE CASO DE USO COM ASPECTO CANDIDATO.................... 34 FIGURA 2.7 USE CASE DE OVERLAP DO ASPECTO SEGURANÇA.............................. 35 FIGURA 2.8 EXEMPLO DE REGRA DE COMPOSIÇÃO............................................... 37 FIGURA 2.9 O GRÁFICO V-GRAPH E SUA COMPOSIÇÃO.......................................... 38 FIGURA 2.10 O GRÁFICO V-GRAPH E SUA REPRESENTAÇÃO................................... 38 FIGURA 2.11 A VISÃO GERAL DA ABORDAGEM GOAL............................................. 39 FIGURA 2.12 ATUALIZAÇÃO DOS MODELOS NO DESENVOLVIMENTO....................... 42 FIGURA 2.13 EFEITOS DE DISPERSÃO E ENROLAÇÃO QUANDO REALIZAMOS PEERS.. 43 FIGURA 2.14 EXEMPLO DE EXTENSION................................................................... 44 FIGURA 2.15 ESTRUTURA DOS ELEMENTOS E CASOS DE USO SLICES........................ 45 FIGURA 2.16 COMPOSIÇÃO DA REALIZAÇÃO DE CASOS DE USO PEER COM CASOS

DE USO SLICES.................................................................................... 45

FIGURA 2.17 REPRESENTAÇÃO DE CASOS DE USO.................................................. 46 FIGURA 2.18 ESTRUTURANDO CASOS DE USO DE INFRA-ESTRUTURA..................... 46 FIGURA 2.19 A ESPECIFICAÇÃO DO CASO DE USO <PERFORM TRANSACTION>....... 47 FIGURA 2.20 O PROCESSO THEME........................................................................... 49 FIGURA 2.21 EXEMPLO ABSTRATO DO GRÁFICO DE VISÃO DE AÇÕES.................... 52 FIGURA 2.22 EXEMPLO ABSTRATO DO GRÁFICO DE AÇÕES LIGADAS..................... 53 FIGURA 2.23 EXEMPLO ABSTRATO DO GRÁFICO DE THEME VIEW.......................... 54 CAPÍTULO 3 FIGURA 3.1 CICLO DE VIDA DO MDSODI............................................................. 66 FIGURA 3.2 O AMBIENTE DISEN E SUA ESTRUTURA EM CAMADAS....................... 70 FIGURA 3.3 REPRESENTAÇÃO DO GERENCIADOR DE WORSPACE .......................... 72 FIGURA 3.4 MODELO DE PROCESSO UTILIZADO NA REQUISITE......................... 73 FIGURA 3.5 DIAGRAMA USE CASE DA FERRAMENTA REQUISITE....................... 74 FIGURA 3.6 ARQUITETURA DETALHADA DA FERRAMENTA REQUISITE.............. 77 FIGURA 3.7 ESQUEMA DE INSTÂNCIAS DA FERRAMENTA REQUISITE................ 79 FIGURA 3.8 REPRESENTAÇÃO DA ARQUITETURA DO DISEN................................. 80 CAPÍTULO 4 FIGURA 4.1 MODELO DE PROCESSO DA ABORDAGEM DAORE..................................... 89 FIGURA 4.2 PROCESSO GERAL DE COSNTRUÇÃO DE REQUISITOS.................................. 90 FIGURA 4.3 UMA TAXONOMIA PARA RNFS. ................................................................. 93 FIGURA 4.4 MODELO DE PROCESSO DE CONSTRUÇÃO DO LEL N A ABORDAGEM

DAORE...................................................................................................... 101

xii

CAPÍTULO 5 FIGURA 5.1 MENU PRINCIPAL DA FERRAMENTA CALEL 118 FIGURA 5.2 TELA DE INCLUSÃO DO LEL 119 FIGURA 5.3 O PROCESSO DE MAPEAMENTO LEL – ONTOLOGIAS 147 FIGURA 5.4 MAPEAMENTO DOS SÍMBOLOS DO TIPO ESTADO 153 FIGURA 5.5 ESTRUTURA HIERÁRQUICA DA ONTOLOGIA EVENTOS 154 FIGURA 5.6 TRECHO DO ARQUIVO DO LEL DOS SÍMBOLOS EM XML 155 FIGURA 5.7 TRECHO DO ARQUIVO DO LEL DOS CENÁRIOS EM XML 155 FIGURA 5.8 TRECHO DO ARQUIVO DE ASPECTOS XML 156 FIGURA 5.9 TRECHO DO ARQUIVO DE ONTOLOGIAS XML 156 CAPÍTULO 6 FIGURA 6.1 MENU PRINCIPAL DA FERRAMENTA REQUISITE 160 FIGURA 6.2 NETBEANS E A FERRAMENTA REQUISITE 161 FIGURA 6.3 BORLAND TOGETHER ARCHITECT E A REQUISITE 162 FIGURA 6.4 DIAGRAMA DE CASOS DE USO DA REQUISITE PROPOSTO 163 FIGURA 6.5 DIAGRAMA DE CLASSES PROPOSTO DA NOVA VERSÃO DA REQUISITE 165 FIGURA 6.6 TELA DE ACESSO AO REQUISITE 166 FIGURA 6.7 NOVO MENU PRINCIPAL DA FERRAMENTA REQUISITE 167 FIGURA 6.8 SUB-MENU DE PROJECT 167 FIGURA 6.9 NEW PROJECT 168 FIGURA 6.10 SUB-MENU DA OPÇÃO LEL 169 FIGURA 6.11 NEW/UPDATE LEL 170 FIGURA 6.12 SUB-MENU DA OPÇÃO USE CASE 171

Lista de Figuras

xiii

Lista de Tabelas

CAPÍTULO 2 TABELA 2.1 RELACIONANDO PROPRIEDADES COM REQUISITOS DOS

STAKEHOLDERS..................................................................................... 28

TABELA 2.2 MAPEAMENTO ENTRE ASPECTOS CANDIDATOS...................................... 29 TABELA 2.3 EXEMPLO DE UMA ESPECIFICAÇÃO DA DIMENSÃO DO ASPECTO........... 30 TABELA 2.4 TEMPLATE PARA ATRIBUTOS DE QUALIDADE......................................... 31 TABELA 2.5 TEMPLATE PARA REQUISITOS NÃO FUNCIONAIS..................................... 32 TABELA 2.6 IDENTIFICAÇÃO DE MATCH POINTS....................................................... 36 TABELA 2.7 CONTRIBUIÇÃO E CORRELAÇÃO............................................................ 39 TABELA 2.8 CARACTERÍSTICAS DE QUALIDADE ISO/IEC 9126................................ 41 TABELA 2.9 ADAPTAÇÃO DOS CONCEITOS DAS CARACTERÍSTICAS DE QUALIDADE

ISO/IEC 9126....................................................................................... 55

TABELA 2.10 SUB-CARACTERÍSTICAS DE COMPARAÇÃO............................................ 56 TABELA 2.11 CRITÉRIOS DE PADRÕES UTILIZADOS NA COMPARAÇÃO....................... 57 TABELA 2.12 COMPARAÇÃO DAS ABORDAGENS AORE.............................................. 59 TABELA 2.13 RESUMO DA COMPARAÇÃO – ABORDAGEM VIEWPOINT........................ 60 TABELA 2.14 RESUMO DA COMPARAÇÃO – ABORDAGEM GOALS............................... 61 TABELA 2.15 RESUMO DA COMPARAÇÃO – ABORDAGEM USE CASE.......................... 62 TABELA 2.16 RESUMO DA COMPARAÇÃO – ABORDAGEM THEME/DOC................... 63 TABELA 2.17 RESUMO GERAL DA COMPARAÇÃO....................................................... 63 CAPÍTULO 3 TABELA 3.1 ESPECIFICAÇÃO DOS ELEMENTOS UTILIZADOS NA MDSODI 68 CAPÍTULO 4 TABELA 4.1 CONCEITOS E ARTEFATOS USADOS NA DAORE.................................... 84 TABELA 4.2 RELAÇÃO ENTRE DIRETRIZES DA DAORE E AS CARACTERÍSTICAS DE

QUALIDADE.......................................................................................... 86

TABELA 4.3 RNFS E ESTRATÉGIAS DE SATISFAÇÃO.................................................. 94 TABELA 4.4 MAPEAMENTO DOS REQUISITOS NÃO FUNCIONAIS E FUNCIONAIS ....... 98 TABELA 4.5 MAPEAMENTO DOS REQUISITOS ORGANIZACIONAIS EM REQUISITOS

FUNCIONAIS E NÃO FUNCIONAIS............................................................ 100

TABELA 4.6 CONTRIBUIÇÕES DOS ASPECTOS............................................................ 104 TABELA 4.7 COMPOSIÇÃO DOS ASPECTOS IDENTIFICADOS....................................... 105 TABELA 4.8 EXEMPLO DE PREENCHIMENTO DA TABELA DE CONFLITOS.................. 106 TABELA 4.9 MAPEAMENTO DOS ELEMENTOS DO LEL PARA OS ELEMENTOS DA

ONTOLOGIA........................................................................................... 107

TABELA 4.10 EXEMPLO DE HIERARQUIA DE CLASSES.................................................. 108 TABELA 4.11 DAORE E OS OBJETIVOS PROPOSTOS................................................... 110 CAPÍTULO 5 TABELA 5.1 REQUISITOS DO SISTEMA....................................................................... 117 TABELA 5.2 REQUISITOS NÃO FUNCIONAIS E ORGANIZACIONAIS DO SISTEMA......... 117 TABELA 5.3 SÍMBOLOS DO LEL ENCONTRADOS NOS REQUISITOS FUNCIONAIS......... 119 TABELA 5.4 SÍMBOLOS DO LEL DETALHADO............................................................ 120 TABELA 5.5 INCLUSÃO DOS REQUISITOS NÃO FUNCIONAIS........................................ 128

xiv

TABELA 5.6 INCLUSÃO DOS REQUISITOS ORGANIZACIONAIS..................................... 128 TABELA 5.7 MAPEAMENTO ENTRE OS TERMOS DO LEL............................................ 129 TABELA 5.8 CENÁRIOS DO LEL................................................................................ 130 TABELA 5.9 CONTRIBUIÇÕES DOS ASPECTOS............................................................ 141 TABELA 5.10 COMPOSIÇÃO DOS ASPECTOS IDENTIFICADOS....................................... 142 TABELA 5.11 RESOLUÇÃO DE CONFLITOS................................................................... 146 TABELA 5.12 TERMOS DO LEL LISTADOS SEGUNDO O SEU TIPO................................. 149 TABELA 5.13 MAPEAMENTO REALIZADO.................................................................... 150 CAPÍTULO 6 TABELA 6.1 MAPEAMENTO ENTRE AS VERSÕES DA REQUISITE................................. 172

Lista de Tabelas

xv

Índice

AGRADECIMENTOS................................................................................................ iv

RESUMO.................................................................................................................... vii ABSTRACT................................................................................................................ viii LISTA DE ABREVIATURAS................................................................................... ix LISTA DE FIGURAS................................................................................................. x LISTA DE TABELAS................................................................................................ xiii 1. INTRODUÇÃO.................................................................................................. 1 1.1 CONTEXTO............................................................................................... 1 1.2 PROBLEMA............................................................................................... 4 1.3 CONTRIBUIÇÕES....................................................................................... 6 1.4 OBJETIVOS............................................................................................... 6 1.5 JUSTIFICATIVA.......................................................................................... 7 1.6 ESCOPO DA DISSERTAÇÃO........................................................................ 7 1.7 METODOLOGIA......................................................................................... 8 1.8 ORGANIZAÇÃO DA DISSERTAÇÃO............................................................. 10 2. DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS....... 12 2.1 CONCEITOS GERAIS DE AOSD................................................................. 13 2.1.1 CONCEITOS DE ASPECTOS, CONCERN E CROSSCUTTING

CONCERNS................................................................................. 14

2.1.2 SEPARAÇÃO DE PROPRIEDADES................................................. 15 2.1.3 COMPOSIÇÃO DE PROPRIEDADES.............................................. 20 2.1.4 A PROGRAMAÇÃO ORIENTADA A ASPECTOS E A LINGUAGEM

ASPECTJ................................................................................... 22

2.2 FASE DE REQUISITOS............................................................................... 26 2.2.1 ABORDAGEM DE VIEWPOINT..................................................... 26 2.2.2 ABORDAGEM AORE UTILIZANDO UML................................... 30 2.2.3 ABORDAGEM GOALS............................................................... 37 2.2.4 ABORDAGEM COM CASOS DE USO............................................. 42 2.2.5 ABORDAGEM THEME/DOC...................................................... 48 2.3 COMPARAÇÃO DAS ABORDAGENS APRESENTADAS.................................. 54 2.4 RESUMO DO CAPÍTULO............................................................................ 64 3 A METODOLOGIA MDSODI E O AMBIENTE DISEN................................. 65 3.1 A METODOLOGIA MDSODI..................................................................... 66 3.2 O AMBIENTE DISEN................................................................................ 70 3.3 A FERRAMENTA REQUISITE................................................................. 72 3.3.1 ASPECTOS FUNCIONAIS............................................................. 74 3.3.2 A ARQUITETURA DA REQUISITE............................................. 76 3.3.3 EXEMPLO DE INSTÂNCIAS DA REQUISITE NO DISEN............. 79 3.4 RESUMO DO CAPÍTULO............................................................................. 81 4. A ABORDAGEM DAORE................................................................................ 82 4.1 OBJETIVOS E DIRETRIZES PRINCIPAIS....................................................... 83 4.2 O PROCESSO DE DESENVOLVIMENTO PROPOSTO...................................... 89 4.2.1 FASE 1 – CONSTRUÇÃO DOS REQUISITOS.................................. 90

xvi

4.2.1.1 LEVANTAMENTO DOS REQUISITOS.............................. 90 4.2.1.2 CONSTRUÇÃO DE REQUISITOS FUNCIONAIS................. 91 4.2.1.3 CONSTRUÇÃO DE REQUISITOS NÃO FUNCIONAIS......... 91 4.2.1.4 CONSTRUÇÃO DE REQUISITOS ORGANIZACIONAIS...... 98 4.2.2 FASE 2 – CONSTRUÇÃO DO LEL............................................... 100 4.2.3 FASE 3 – DEFININDO ASPECTOS CANDIDATOS........................... 102 4.2.3.1 IDENTIFICANDO CONTRIBUIÇÕES............................ 103 4.2.3.2 DEFININDO COMPOSIÇÃO........................................ 104 4.2.3.3 IDENTIFICANDO CONFLITOS.................................... 105 4.2.4 FASE 4 - MAPEAMENTO DE ONTOLOGIAS................................. 107 4.2.5 GERAÇÃO DE ARQUIVOS PARA EXPORTAÇÃO........................... 108 4.3 CONSIDERAÇÕES SOBRE A ABORDAGEM DAORE.................................... 109 4.3.1 COM RELAÇÃO AOS OBJETIVOS PROPOSTOS............................. 109 4.3.2 USO NA REQUISITE E NO PROJETO DISEN................................. 110 4.3.3 DIFERENÇAS COM AS ABORDAGENS ESTUDADAS...................... 111 4.4 RESUMO DO CAPÍTULO............................................................................. 111 5. EXPERIMENTAÇÃO: CONTROLE DE EVENTOS....................................... 113 5.1 OBJETIVOS............................................................................................... 114 5.2 A ESCOLHA DA FERRAMENTA DE IMPLEMENTAÇÃO................................. 114 5.3 O SISTEMA PROPOSTO.............................................................................. 115 5.4 FASE 1 - IDENTIFICANDO OS REQUISITOS ................................................ 116 5.5 FASE 2 – CONSTRUINDO O LÉXICO........................................................... 118 5.5.1 ANALISANDO INTERDEPENDÊNCIAS E RESOLVENDO CONFLITOS 129 5.5.2 CONSTRUINDO OS CENÁRIOS..................................................... 129 5.5.3 ANALISANDO OS CENÁRIOS....................................................... 139 5.6 FASE 3 - DEFINIÇÃO DE ASPECTOS CANDIDATOS..................................... 139 5.7 FASE 4 - MAPEAMENTO DE ONTOLOGIAS................................................. 147 5.8 GERAÇÃO DE ARQUIVOS PARA EXPORTAÇÃO.......................................... 154 5.9 RESUMO DO CAPITULO............................................................................. 157 6 A FERRAMENTA REQUISITE E A ABORDAGEM DAORE....................... 158 6.1 SITUAÇÃO ATUAL.................................................................................... 158 6.1.1 MENU PRINCIPAL DA REQUISITE 159 6.2 SITUAÇÃO FUTURA................................................................................... 161 6.2.1 PROJETO DISEN........................................................................ 161 6.2.2 MUDANÇAS PREVISTAS NA REQUISITE...................................... 162 6.2.3 ANÁLISE DO IMPACTO DAS MUDANÇAS..................................... 171 6.3 RESUMO DO CAPÍTULO............................................................................. 176 7 CONCLUSÃO.................................................................................................... 177 7.1 CONTRIBUIÇÕES....................................................................................... 177 7.2 LIMITAÇÕES E TRABALHOS FUTUROS...................................................... 178 7.3 CONSIDERAÇÕES FINAIS........................................................................... 179 7.4 TRABALHOS SUBMETIDOS........................................................................ 180 REFERÊNCIAS BILBIOGRÁFICAS................................................................ 182 ANEXOS............................................................................................................ 189

Índice

1. Introdução 1

CAPÍTULO

11

INTRODUÇÃO

The best preparation for good work tomorrow is to do good work today.

Elbert Hubbard

NNeess ttee ccaappíí ttuulloo aapprreesseennttaammooss uummaa vviissããoo ggeerraa ll ddaa pprrooppooss ttaa ddee

ddiisssseerrttaaççããoo.. IInniicc iiaa llmmeennttee,, ddeessccrreevveemmooss oo ccoonntteexxttoo nnoo qquuaall eess ttee

ttrraabbaallhhoo ddee ppeessqquuiissaa ssee iinnsseerree.. AA sseegguuiirr,, ddiissccuuttiimmooss qquuaall oo pprroobblleemmaa

qquuee pprreetteennddeemmooss rreessoollvveerr ee qquuaaiiss ooss oobbjjeett iivvooss ee ff iinnaa lliiddaaddeess ddaa

ppeessqquuiissaa,, ppoorr ffiimm aapprreesseennttaammooss aa mmeettooddoollooggiiaa ddee ppeessqquuiissaa qquuee ffooii

aaddoottaaddaa,, ddeelliimmiittaammooss oo eessccooppoo ddaa pprrooppooss ttaa ddee ddiisssseerrttaaççããoo ee

ddeessccrreevveemmooss aa eess ttrruuttuurraa ddooss ccaappíí ttuullooss ddeess ttee ttrraabbaallhhoo..

11..11 CCoo nntteexxttoo

O processo de desenvolvimento de sistemas de informação sofreu uma quebra de

paradigma com o surgimento da orientação a objetos na década de 80 (SHAELER &

MELLOR, 1990). Até então, os sistemas eram desenvolvidos de forma procedural e

estruturada, isso quando eram desenvolvidos seguindo um processo de desenvolvimento, pois

a maioria ignorava os conceitos propostos ou até mesmo desconheciam o processo em si.

Infelizmente, os conceitos advindos com a orientação a objetos não eram fáceis de s e

incorporar ao cotidiano, mesmo que os defensores da orientação a objetos afirmassem que “a

orientação a objetos é uma coisa natural, pois o mundo é orientado a objetos”

1. Introdução 2

(www.forumweb.com.br/artigos/artigos.php? action=file&id=535). Muitas vezes, estas dificuldades

na assimilação dos conceitos se deviam à formação acadêmica, por esta ser de base

estruturada e, por outra, ser uma maneira completamente diferente de abstrair conceitos do

mundo real.

Atualmente, uma nova abordagem no desenvolvimento de sistemas tem sido

pesquisada e utilizada: o Desenvolvimento de Sistemas baseado na Orientação a Aspectos -

AOSD.

Esta abordagem, em parte, segue os conceitos de (DIJKSTRA, 1976), que

apresenta o princípio da separação de concerns1, onde para superar a complexidade, deve-se

resolver um concern importante por vez. Em engenharia de software, esse princípio está

relacionado à modularização e à decomposição de sistemas (PARNAS, 1972). Os sistemas de

software complexos devem ser decompostos em unidades modulares menores e claramente

separados, cada uma lidando com um único concern. Se bem realizada, a separação de

concerns pode oferecer muitos benefícios cruciais (DIJKSTRA, 1976) (TARR, 1999). Ela

oferece suporte a uma melhor manutenibilidade com alterações aditivas, em vez de evasivas,

melhor compreensão e redução da complexidade, melhor reusabilidade e uma integração de

componentes simplificada.

Para (ELRAD et al., 2001 apud SOUZA, 2004), assim como o paradigma

orientado a objetos (POO) não descarta as idéias de dados e operações do paradigma

estrutural, o paradigma orientado a aspectos (POA) não rejeita a tecnologia existente. O

paradigma orientado a aspectos complementa o paradigma orientado a objetos a fim de

auxiliar na separação daquelas preocupações que o POO manipula deselegantemente (não

possuindo recursos para fazer tal tarefa, necessitando de outras formas que tornam o código

mais difícil de entender e manutenir). Para isso, o paradigma orientado a aspectos provê

mecanismos para localizar e compor os crosscutting concerns2 (ou aspectos) com as unidades

que eles afetam de maneira não invasiva, ou seja, evitando que fiquem explicitamente

espalhados nos artefatos de software ou misturados com as preocupações específicas desses

artefatos.

Esse é um paradigma emergente (ELRAD et al., 2001 apud SOUZA, 2004) e, o

estado atual da pesquisa nessa área pode ser comparado ao estado da pesquisa em orientação a

1 Um concern pode ser definido como: questão, característica ou preocupação. Porém, neste trabalho utilizaremos o termo em inglês. 2 Crosscutting concerns podem ser traduzidos como preocupações ou características transversais. Em Piveta (2004) foi proposto que se utilizasse o termo concerns transversais, porém, neste trabalho, utilizaremos o termo em inglês.

1. Introdução 3

objetos há vinte anos atrás: os conceitos básicos estão se formando e um grupo crescente de

pesquisadores está usando esses conceitos em seus trabalhos sobre orientação a aspectos.

As pesquisas realizadas em Early Aspects têm evoluído muito desde 2002

(RASHID et al, 2002). Por conseqüência, várias abordagens têm se preocupado com a

identificação de aspectos nas fases iniciais do desenvolvimento, principalmente na fase de

requisitos, como a Abordagem Viewpoint (RASHID et al., 2002) (RASHID et al., 2003),

Metas (YU et al., 2004) (SILVA&LEITE, 2005b), Casos de Uso (JACOBSON&NG, 2005)

(SOUZA, 2004) e Theme/DOC (CLARKE&BANIASSAD, 2005). Estas abordagens tiveram

início na orientação não aspectos e foram adaptadas e desenvolvidas a fim de se moldar ao

novo paradigma da orientação a aspectos.

Ainda se tratando da abordagem orientada a objetos, muitos projetos se

desenvolveram utilizando esta abordagem em Universidades Brasileiras (UFPE, UEM, UFRJ,

PUC-Rio, entre outras) e ainda estão em desenvolvimento, mesmo porque, a abordagem de

aspectos não chega a ser uma quebra de paradigmas, mas sim uma extensão da abordagem

que está sendo utilizada (JACOBSON&NG, 2005).

No Paraná, mais especificamente na Universidade Estadual de Maringá (UEM),

membros do Grupo de Estudos e Pesquisa de Sistemas de Software Distribuídos (GESSD),

desenvolvem vários trabalhos relacionados à Metodologia de Desenvolvimento de Software

Distribuído – MDSODI (GRAVENA, 2000) (HUZITA, 1999) .

A MDSODI é uma metodologia de desenvolvimento de software que oferece

suporte à especificação de alguns aspectos relacionados a sistemas distribuídos desde as fases

iniciais de projeto. A notação desta metodologia baseia-se na Unified Modeling Language –

UML (UML, 2006), mas adota também algumas extensões para a representação de sistemas

distribuídos. Dessa forma é possível abordar de forma clara os aspectos relacionados à

distribuição do sistema desde, as fases iniciais do processo de desenvolvimento de software.

Como a MDSODI é uma metodologia que cobre todo o processo de

desenvolvimento de software, é natural imaginar-se um cenário onde serão utilizadas várias

ferramentas de apoio ao desenvolvimento de software cada qual criando e, possibilitando a

manutenção necessária dos vários artefatos relativos às diversas fases do processo. Estas

ferramentas poderão ter sido criadas especialmente para esta metodologia, ou então serem

ferramentas já existentes no mercado, produzidas por terceiros, cada uma com sua

especialidade e potencialidade.

Na mesma universidade, existe também o projeto de um ambiente distribuído de

desenvolvimento de software, denominado Distributed Software Engineering Environment -

1. Introdução 4

DiSEN (PASCUTTI, 2002) (HUZITA,2004). O ambiente DiSEN foi concebido com vistas à

utilização da metodologia MDSODI, enquanto que na sua arquitetura, pode-se observar que o

mesmo oferece suporte a agentes. Entende-se, que neste ambiente, estarão sendo utilizadas

várias ferramentas de desenvolvimento de software, onde cada uma delas estará produzindo

artefatos como resultados do trabalho do desenvolvedor de software.

No ambiente do projeto DiSEN a preocupação com o gerenciamento de requisitos

surgiu com a elaboração de uma ferramenta própria a REQUISITE (BATISTA, 2003). Esta

ferramenta foi desenvolvida baseada nos conceitos de orientação a objetos, seguindo ainda a

metodologia MDSODI para ambientes distribuídos, porém não considera os crosscutting

concerns, tanto em nível de desenvolvimento da ferramenta em si como em nível de projeto

dos requisitos inseridos.

A elaboração de uma nova abordagem que contemple a identificação e composição

dos crosscutting concerns e que esteja inserida no contexto da metodologia MDSODI

permitirá a atualização dos projetos a serem desenvolvidos e os que estão atualmente sendo

desenvolvidos, como o projeto do ambiente DiSEN e suas ferramentas de apoio.

11..22 PPrroobblleemmaa

As motivações para o surgimento do paradigma orientado a aspectos originaram-

se, principalmente, a partir de problemas encontrados na codificação de sistemas. Por isso, a

maior parte da pesquisa nessa área tem sido focada nas atividades orientadas à

implementação. Atualmente, a orientação a aspectos vem sendo utilizada, q u a s e que

exclusivamente, na codificação de sistemas através de linguagens como AspectJ (KICZALES,

2001) e Hyper/J (OSSHER&TARR, 2000).

Recentemente, a comunidade de Engenharia de Software tem se interessado em

propagar a utilização dos fundamentos e práticas desse paradigma para as atividades iniciais

do ciclo de desenvolvimento (SOUZA, 2004). Algumas das razões que impulsionam essa área

de pesquisa são:

· Antecipar a identificação e a modelagem de aspectos;

· Antecipar o raciocínio sobre quais unidades devem ser afetadas por um aspecto e

como a composição entre o aspecto e as unidades afetadas por ele deve ser realizada;

· Permitir que os benefícios da utilização do paradigma orientado a aspectos sejam

obtidos ao longo de todo processo de desenvolvimento e não apenas nos artefatos de

implementação;

1. Introdução 5

· Possibilitar que o entendimento de um sistema implementado com uma linguagem

orientada a aspectos possa ser obtido através de modelos de análise e projeto, ao invés

de exigir que ele dependa da análise do código do sistema.

Desde 2002, algumas abordagens iniciais vêm sendo propostas nesse sentido.

Alguns trabalhos já se preocupam com outras fases do desenvolvimento, desde requisitos até

a implementação, (SOUZA, 2004) (JACOBSON & NG, 2005) (CLARKE & BANIASSAD,

2005). Porém, todos os trabalhos pesquisados não possuem uma maneira clara e objetiva de

tratar alguns problemas relacionados à fase de requisitos. Alguns problemas gerais

encontrados foram:

· A identificação e tratamento de requisitos organizacionais;

· A identificação de crosscutting concerns (sendo estes funcionais, não-funcionais ou

até mesmo organizacionais);

· Representação gráfica do modelo, em muitos casos o modelo não é adequado ou a

ferramenta para tal não está disponível, como podemos observar no Capítulo 3, onde

realizamos um estudo comparativo das abordagens existentes; e

· Em algumas abordagens, a representação dos requisitos não funcionais (RNF)

(CHUNG et al., 2000) se confunde com características adicionais do sistema, como no

trabalho de Jacobson & Ng (2005).

Adicionalmente podemos citar alguns problemas específicos ligados ao nosso

projeto no ambiente DISEN:

· Inserção no contexto da metodologia MDSODI;

· Exportação de modelos no padrão XML, usando XML 3 Schema para definir padrões

a serem utilizados. Estes modelos englobam: Léxico Extendido da Linguagem4 (LEL),

aspectos candidatos5, cenários6 e ontologias7.

Algumas abordagens estudadas, relativas à fase de requisitos, como: como a

Abordagem Viewpoint (RASHID et al., 2002) (RASHID et al., 2003), Metas (YU et al., 2004)

(SILVA & LEITE, 2005b), Casos de Uso (JACOBSON & NG, 2005) (SOUZA, 2004) e

Theme / DOC (CLARKE & BANIASSAD, 2005), possuem vantagens e desvantagens em

relação a outras. Esse fato foi a principal motivação para o desenvolvimento desta proposta de

3 Uma definição de XML Schema e seus conceitos principais podem ser encontrados em XML (2006). 4 LEL – Léxico Extendido da Linguagem (Language Extended Lexicon), técnica que auxilia a descrição de cenários utilizando linguagem natural – encontramos também o termo LAL (Léxico Ampliado da Linguagem) que significa a mesma coisa (Leite, 1997) 5 Veremos os conceitos de aspectos candidatos no Capítulo 3. 6 Conceitos de cenários e sua relação com o LEL podem ser encontrados em Leite (1997). 7 Conceitos de ontologias pode ser encontradas em Breitman (2005).

1. Introdução 6

dissertação (veremos mais no Capítulo 3, item 3.5 - Análise Comparativa das Abordagens em

AORE).

11..33 CCoonnttrriibbuuiiççõõeess

A principal contribuição deste trabalho é integrar a metodologia MDSODI ao

desenvolvimento de software orientado a aspectos.

Esta contribuição é baseada na técnica do LEL utilizada pelo ambiente DISEN na

elicitação dos requisitos através da ferramenta Requisite. Com o desenvolvimento de uma

nova abordagem que possa integrar o LEL na orientação a aspectos, de forma a facilitar a

identificação dos aspectos candidatos nas fases iniciais do processo de desenvolvimento, irá

contribuir para aumentar o reuso de componentes especificados.

11..44 OObbjjeett iivvooss

O objetivo geral desta dissertação é apresentar uma nova abordagem de orientação

a aspectos para a fase de engenharia de requisitos, que se utilize do LEL, para que possa

facilitar a identificação e a separação de concerns nos projetos elaborados com base na

metodologia MDSODI.

A partir desse objetivo geral, definimos os seguintes objetivos específicos:

- Compreender os fundamentos do Desenvolvimento de Sistemas baseado na

Orientação a Aspectos nas fases iniciais do processo de desenvolvimento;

- Propor uma nova abordagem através da análise e seleção de pontos de vantagens

oferecidas pelas abordagens existentes, permitindo uma abordagem mais flexível que

possibilite o suporte tanto na adaptação de projetos existentes (por se utilizar do LEL)

quanto para novos projetos; e

- Realizar a validação utilizando a abordagem proposta através da experimentação, onde

o projeto a ser desenvolvido será o mesmo apresentado pela ferramenta REQUISITE

para que se possa avaliar o impacto das mudanças propostas na ferramenta e no

ambiente DISEN.

1. Introdução 7

11..55 JJuusstt iiff iiccaattiivvaa

Os fundamentos do paradigma orientado a aspectos podem ser usados de maneira

complementar aos do paradigma orientado a objetos8 (SOUZA, 2004). Por isso, o paradigma

orientado a aspectos pode ser considerado uma evolução, não uma revolução, em relação ao

paradigma orientado a objetos e pode ser usado para melhorar técnicas existentes.

A quebra de paradigmas sempre foi um grande problema na área de

desenvolvimento de sistemas, em particular na década de 80 com o surgimento da orientação

a objetos. Podemos dizer que foi uma grande revolução, pois apresentava conceitos até então

desconhecidos e completamente diferentes dos usados na época.

A orientação a aspectos, por outro lado, não apresenta conceitos tão diferentes

assim, pois ela apenas agrega alguns conceitos à abordagens que já existem. Desde o seu

surgimento, no fim da década de 90, voltada apenas para a implementação, é um exemplo

disso, uma vez que adicionava construções e mecanismos específicos para o tratamento de

aspectos em linguagens de programação, como AspectJ (KICZALES., 2001), que estende a

linguagem orientada a objetos Java (GOSLING et al., 2000).

Atualmente, as abordagens existentes em orientação a aspectos possuem algumas

vantagens, como:

(i) Descrição detalhada das fases principais do desenvolvimento;

(ii) Características próprias definidas pelo tipo de abordagem considerada;

Porém, todas possuem uma característica negativa: não oferece a p o i o à

identificação de aspectos.

Pelos motivos acima descritos, a direção que escolhemos para alcançar o objetivo

geral deste trabalho foi o de propor uma nova abordagem que facilite a identificação de

aspectos nas fases iniciais do processo de desenvolvimento utilizando a metodologia

MDSODI para sistemas distribuídos, que estejam inseridas no contexto de cenários utilizando

o LEL.

11..66 EEssccooppoo ddaa DDiissssee rrttaaççããoo

Conforme mencionado anteriormente, para alcançar o objetivo geral desta

dissertação, decidimos adaptar algumas características das abordagens existentes para as fases

iniciais do processo de desenvolvimento.

8 Mas não se limita ao paradigma orientado a objetos, podendo ser usado também em conjunto com outros

paradigmas como o estruturado e o funcional (CONSTANTINIDES & HASSOUN, 2002).

1. Introdução 8

Nosso trabalho focará a fase de requisitos, uma vez que as abordagens estudadas

se referem, principalmente, à fase de requisitos e que nosso objetivo é identificar os aspectos

nesta fase. Assim, deixaremos de abordar o tratamento de projeto, implementação e testes,

sendo um trabalho a ser feito futuramente.

11..77 MMeettooddoo llooggiiaa ddee DDeesseennvvoo llvviimmeennttoo ddaa PPeessqquuiissaa

A pesquisa em Engenharia de Software pode ser conduzida através de quatro

métodos: o científico, o de engenharia, o experimental e o analítico (WOHLIN, 2000 apud

TRAVASSOS, 2002).

O método científico foca na observação de um ambiente e na tentativa de extrair

dele algum modelo ou teoria que possa explicar o fenômeno estudado. O método de

engenharia, por sua vez, é baseado na observação de soluções existentes, na identificação de

problemas nessas soluções e na sugestão de abordagens para melhorar as soluções analisadas.

Já o método experimental pretende fornecer um modelo novo para solução de um problema e

tenta estudar o impacto desse modelo. Por fim, o método analítico oferece uma base analítica

(ou matemática) para o desenvolvimento de modelos.

Este trabalho de pesquisa seguiu o método de engenharia (baseado na Figura 1.1).

1. Introdução 9

1 - Revisão

Bibliográfica

2 - Análise das

Abordagens

4 - Elaboração da Nova

Abordagem

5 - Aplicação na nova

Abordagem

6 - Validação

7 - Apresentação

- AOSD

-MDSODI, DISEN e REQUISITE

- Abordagens existentes em AORE

- Análise Comparativa; - Definição de pontos principais a serem considerados

-Nova abordagem a partir dos pontos considerados

- através da experimentação

-Análise do impacto das mudanças no ambiente DISEN e na ferramenta REQUISITE

- Apresentação da dissertação

3 – Exame de

Qualificação

-Apresentação da proposta de qualificação

FIGURA 1.1 – ESTRUTURA DA PESQUISA SEGUIDA.

Na Figura 1.1 temos a estrutura de pesquisa que foi seguida:

1. Inicialmente foi fei ta u m a revisão bibliográfica sobre os conceitos de

AOSD, a metodologia MDSODI, o ambiente DISEN e a ferramenta

REQUISITE. Após isso, foi elaborado u m estudo sobre algumas

abordagens existentes para a AORE: Viewpoint (RASHID et al., 2002)

(RASHID et al., 2003), Metas (YU et al., 2004) (SILVA & LEITE, 2005b),

Casos de Uso (JACOBSON & NG, 2005) (SOUZA, 2004) e Theme / DOC

(CLARKE & BANIASSAD, 2005);

1. Introdução 10

2. Nesta fase foi realizada uma análise comparativa das abordagens para

identificar os conceitos, vantagens e desvantagens de cada uma, ou seja, os

elementos relevantes foram identificados e mapeados;

3. Foi apresentada a proposta de qualificação para o mestrado;

4. Baseado nos pontos considerados no passo 2 foi elaborada a nova

abordagem de forma a apresentar características identificadas em algumas

das abordagens estudadas, além de possuir características próprias;

5. Aplicação da nova abordagem em um estudo de caso para validar a mesma.

Este estudo de caso foi o mesmo realizado por ocasião da validação da

ferramenta REQUISITE, a fim de se obter um comparativo de avaliação

utilizando duas abordagens diferentes;

6. Análise das mudanças para avaliar o impacto na ferramenta REQUISITE e

no projeto DISEN, com o objetivo de sugerir mudanças e pontos críticos

para a validação da nova abordagem, ou seja, o quanto esta mudança foi

benéfica para o projeto; e

7. Apresentação do trabalho.

11..88 OOrrggaanniizzaaççããoo ddaa DDiissssee rrttaaççããoo

Além deste capítulo introdutório e de um glossário e um anexo que incluímos no

final da dissertação, este trabalho é composto pelos seguintes capítulos:

· Capítulo 2: apresenta uma visão geral do Desenvolvimento Orientado a Aspectos e

descreve algumas abordagens utilizadas para a fase de Requisitos. Ao final do capítulo

é apresentado um comparativo entre as abordagens. Este estudo comparativo foi

utilizado como base da confecção da nova abordagem;

· Capítulo 3: apresenta uma visão geral sobre a metodologia MDSODI, o ambiente

DiSEN e a ferramenta REQUISITE e como se relacionam;

· Capítulo 4: detalha a nova abordagem, descrevendo em cada fase o que dever ser feito;

· Capítulo 5: descreve a utilização da abordagem apresentada no Capítulo 4 em uma

experimentação. O objetivo principal é propiciar a validação da nova abordagem, de

maneira que se possa avaliar o impacto sobre a ferramenta REQUISITE e o projeto

DiSEN;

1. Introdução 11

· Capítulo 6: apresenta o impacto da abordagem DAORE na ferramenta Requisite, suas

principais implicações, análises e comparações; e

· Capítulo 7: apresenta as conclusões, enumera as contribuições e propõe trabalhos

futuros.

2.Desenvolvimento de Software Orientado a Aspectos 12

CAPÍTULO

22

DESENVOLVIMENTO DE SOFTWARE ORIENTADO A

ASPECTOS

O que sabemos é uma gota, o que ignoramos é um oceano. Isaac Newton

OO ddeesseennvvoollvviimmeennttoo ddee ssooffttwwaarree tteemm ss iiddoo aa llvvoo ddee eess ttuuddooss

((CCHHIITTCCHHYYAANN eett aa ll,, 22000055bb)) ((SSIILLVVAA,, 22000044)) aa ff iimm ddee ggaarraanntt iirr aa

qquuaalliiddaaddee ddoo pprroodduuttoo ffiinnaa ll,, oouu ssee jjaa,, oo ssooffttwwaarree eemm ss ii,, ee ddoo pprróópprriioo

pprroocceessssoo ddee ddeesseennvvoollvviimmeennttoo qquuee oo ddeeffiinniiuu.. IIss ttoo tteemm ooccoorrrriiddoo ddeessddee

mmeeaaddooss ddaa ddééccaaddaa ddee 7700 ccoomm oo ddeesseennvvoollvviimmeennttoo eess ttrruuttuurraaddoo,, sseennddoo

aa AAnnáálliissee EEss ttrruuttuurraaddaa ddee SSiiss tteemmaass oorriiuunnddaa ddaa pprrooggrraammaaççããoo

eess ttrruuttuurraaddaa..

OO DDeesseennvvoollvviimmeennttoo ddee SSooffttwwaarree OOrr iieennttaaddoo aa AAssppeecc ttooss ((AAOOSSDD)) éé

aaddvviinnddoo ddaa pprrooggrraammaaççããoo oorriieennttaaddaa aa aassppeecc ttooss ,, aassss iimm ccoommoo ffooii nnaa

ééppooccaa ddoo ddeesseennvvoollvviimmeennttoo eess ttrruuttuurraaddoo ddee ss iiss tteemmaass ..

AAss ttééccnniiccaass eexxiiss tteenntteess ddee AAOOSSDD pprroovvêêmm uummaa ffoorrmmaa ss iiss tteemmáátt iiccaa ddee

iiddeenntt iiff iiccaarr,, mmoodduullaarr iizzaarr,, rreepprreesseennttaarr ee ccoommppoorr ooss ccrroossssccuuttttiinngg

ccoonncceerrnnss ((pprroopprriieeddaaddeess ttrraannssvveerrssaaiiss )) ccoommoo:: sseegguurraannççaa,, mmoobbiilliiddaaddee ee

rreeggrraass ddee tteemmppoo rreeaall ((CCHHIITTCCHHYYAANN eett aa ll..,, 22000055))..


EEmm 11999999,, eemm uumm ccoonnggrreessssoo ddee EEnnggeennhhaarr iiaa ddee RReeqquuiiss iittooss eemm

LLyymmeerr iicckk –– IIrree llaanndd,, ffoo ii uutt iilliizzaaddoo ppeellaa pprriimmeeiirraa vveezz oo tteerrmmoo

““AAssppeecctt--oorriieenntteedd RReeqquuiirreemmeennttss EEnnggiinneeeerriinngg”” oouu AAOORREE

((GGRRUUNNDDYY,,11999999)),, ddeemmoonnss ttrraannddoo oo iinntteerreessssee ee aa pprreeooccuuppaaççããoo eemm

ttrraattaarr eess tteess ccrroossssccuuttttiinngg ccoonncceerrnnss jjáá nnaa ffaassee ddee rreeqquuiiss iittooss .. EEmm 22000022,,

eemm EEsssseenn--AAlleemmaannhhaa,, iigguuaallmmeennttee nnoo ccoonnggrreessssoo ddee EEnnggeennhhaarr iiaa ddee

RReeqquuiiss iittooss oo tteerrmmoo EEaarrllyy AAssppeeccttss ((RRAASSHHIIDD eett aa ll,, 22000022)) ffoo ii uussaaddoo

ppeellaa pprr iimmeeiirraa vveezz.

EEaarrllyy AAssppeeccttss tteemm ccoommoo ffooccoo pprriinncc iippaa ll aa ggeerrêênncciiaa ddaass pprroopprriieeddaaddeess

ttrraannssvveerrssaa iiss nnooss eess ttáággiiooss iinniicc iiaa iiss ddoo ddeesseennvvoollvviimmeennttoo,, eenngglloobbaannddoo

ddeessddee aa eennggeennhhaarr iiaa ddee rreeqquuiiss iittooss aattéé oo ddeessiiggnn ddee aarrqquuiittee ttuurraa..

NNeess ttee ccaappíí ttuulloo éé aapprreesseennttaaddoo uummaa vviissããoo ggeerraa ll ddooss pprriinncc iippaa iiss

ccoonncceeiittooss ddoo ddeesseennvvoollvviimmeennttoo ddee ssooffttwwaarree oorriieennttaaddoo aa aassppeecc ttooss ee

aallgguummaass aabboorrddaaggeennss eexxiiss tteenntteess eemm AAOOSSDD.. IInniicc iiaa llmmeennttee,, ddeessccrreevvee--

ssee ooss ccoonncceeiittooss bbááss iiccooss ddaa oorriieennttaaççããoo aa aassppeecc ttooss ,, ccoommoo aa sseeppaarraaççããoo

ddee pprroopprriieeddaaddeess ,, ppoorr eexxeemmpplloo .. EEmm sseegguuiiddaa,, éé ddeettaa llhhaaddoo aass

mmoottiivvaaççõõeess ppaarraa oo ssuurrggiimmeennttoo ddeessssee ppaarraaddiiggmmaa ddee

ddeesseennvvoollvviimmeennttoo,, ddeessccrreevveennddoo ooss pprroobblleemmaass qquuee ee llee ssee pprrooppõõee aa

ssoolluucc iioonnaarr ee aa llgguummaass aabboorrddaaggeennss eexxiiss tteenntteess eemm AAOORREE.. PPoorr ffiimm,, éé

rreeaa lliizzaaddaa uummaa ccoommppaarraaççããoo eennttrree aass aabboorrddaaggeennss aapprreesseennttaaddaass ,,

eennffaatt iizzaannddoo sseeuuss ppoonnttooss ffoorrtteess ee ffrraaccooss nnaass ccoonnss iiddeerraaççõõeess ffiinnaa iiss ,, aa

qquuaall sseerráá oo ppoonnttoo ddee ppaarrttiiddaa ppaarraa oo pprróóxxiimmoo ccaappíí ttuulloo..

22..11 CCoo nncceeiittooss GGeerraa iiss ddee DDeesseennvvoollvv iimmeennttoo OOrriieennttaaddoo aa AAssppeeccttooss ((AAOOSSDD))

Alguns conceitos relacionados à AOSD são muito importantes para o perfeito

entendimento deste paradigma, pois são a partir destes que todo o processo é baseado.

Assim, veremos alguns destes conceitos a seguir.


22..11..11 CCoo nncceeiittoo ddee aassppeeccttooss,, ccoonncceerrnn ee ccrroossssccuuttttiinngg ccoonncceerrnn

Encontramos algumas definições de aspectos na literatura pesquisada, que se

segue:

Segundo Jr (2003) aspectos são representações de concerns que atravessam as

representações de outros concerns.

Para Clarke & Baniassad (2004, 2005) os aspectos são comportamentos que

estão misturados e espalhados através do sistema e é um tipo particular de concern.

Brito & Moreira (2003) definem um concern como sendo uma questão ou

assunto de interesse no sistema de software, exemplificando ainda que concern pode ser

um objetivo ou um conjunto de propriedades que o sistema deve satisfazer.

Segundo Tekinerdogan (2004) um concern é um subproblema.

Para Mili et al. (2004) um concern é um conjunto de requisitos relacionados.

Para Silva & Leite (2005) um concern é uma característica do sistema ou do

domínio que seja interessante analisar quer isoladamente quer em conjunto com outras.

Figueiredo et al. (2005) argumenta que um concern está crosscutting se está

atravessado em outros concerns em um módulo ou em múltiplos módulos do sistema.

Para Chitchyan et al. (2005a) o termo crosscutting concerns se refere a fatores

de qualidade ou funcionalidades do software que não podem ser eficientemente

modularizados usando técnicas existentes de desenvolvimento de software (a abordagem

orientada a objetos).

Nesse trabalho será utilizado o conceito de que um concern é uma propriedade,

sendo esta propriedade um requisito funcional ou não funcional (YU et al, 2004) e que um

crosscutting concern é uma propriedade transversal, ou seja, um requisito (ou propriedade)

que está transversal em relação a outros requisitos é um forte candidato a ser um aspecto.

Existem vários exemplos de comportamentos que podem ser citados como

aspectos e que possuem este comportamento ou funcionalidade de precisar ser carregada

em diferentes módulos de um código orientado a objeto, como segurança, persistência e

sincronização, entre outros.

Atualmente há uma preocupação crescente em conseguir identificar aspectos

nas fases iniciais do processo de desenvolvimento, sendo alvo de estudos comparativos de


abordagens que tratam da fase de requisitos (CHITCHYAN et al, 2005a) (BAKKER et al,

2005).

Assim, temos o termo early aspects que define os crosscutting concerns ou as

propriedades transversais identificadas nas fases iniciais do ciclo de desenvolvimento de

software (RASHID et al, 2002) (ARAUJO et al, 2005). Estas fases incluem a análise de

requisitos, análise de domínio e a fase de projeto da arquitetura.

As técnicas de AOSD provêm uma maneira sistemática de identificar,

modularizar, representar e compor os crosscutting concerns, ou seja, separação e

composição de propriedades (CHITCHYAN et al, 2005a).

A seguir é descrito estes dois conceitos, que são os pilares da orientação a

aspectos.

22..11..22 SSeeppaa rraaççããoo ddee PPrroo pprriieeddaa ddeess

Produzir software com qualidade sempre foi um dos objetivos de todo o

desenvolvedor de software. P ressman (2005) alega que além de produzir software de

qualidade deve-se tentar fazê- lo em um menor espaço de tempo possível, sendo esse um

dos principais objetivos da Engenharia de Software.

Para alcançar tal objetivo, diversas abordagens foram propostas ao longo dos

anos: Análise Estruturada de Sistemas (GANE & SARSON, 1977), Análise Essencial de

Sistemas (MCMENAMIN & PALMER, 1984), Análise Orientada a Objetos (SHLAER &

MELLOR, 1990), P r o c e s s o Catalysis (SOUZA & WILLS, 1 9 9 5 ), Processo

Unificado/UML (BOOCH et al, 1999) (JACOBSON et al., 1999) (SCOTT, 2003) e o

Desenvolvimento Orientado a Aspectos (JACOBSON & NG, 2005) (CLARKE &

BANIASSAD, 2005).

Guezzi apud S ouza ( 2004) estabeleceu alguns princípios que devem ser

aplicados ao longo do processo de desenvolvimento e nos artefatos de software: separação

de propriedades, modularidade, rigor e formalidade, incrementalidade, abstração,

generalidade e antecipação de mudanças.

O objetivo da separação de propriedades é identificar e modularizar as partes

do software que são relevantes para um conceito em particular, meta ou propósito (BRITO

& MOREIRA, 2003).


Com isso, este princípio permite que se reduza o raciocínio a uma quantidade

factível (DIJKSTRA, 1976). Esse princípio estabelece que um problema possa s e r

decomposto em unidades menores, claramente separadas, de maneira que cada uma delas

represente uma única preocupação (AKSIT et al. apud SOUZA, 2004). A idéia básica é

manipular com uma preocupação do sistema de cada vez, ou seja, o velho e bom “dividir

para conquistar”. Como conseqüência, a aplicação desse princípio possibilita:

· Diminuir a complexidade do desenvolvimento de software, concentrando-

se em diferentes preocupações separadamente;

· Raciocinar sobre diferentes preocupações de maneira relativamente

independente;

· Facilitar a inserção/remoção de preocupações na aplicação;

· Dividir esforços e separar responsabilidades entre membros da equipe de

desenvolvimento; e

· Melhorar a modularidade de artefatos de software.

Souza (2004) aponta ainda que quando os artefatos de software possuem a

capacidade de separação de propriedades, elas tendem a ser similares (forte coesão) e a

dependência entre os artefatos é minimizada (fraco acoplamento).

Conseqüentemente, mudanças em artefatos relacionadas a uma propriedade,

tendem a ter um efeito limitado ou até mesmo nenhum efeito em artefatos relacionados a

outras propriedades. Isso facilita a compreensão, evolução, adaptação, customização e

reuso dos artefatos de software.

Para implementar este princípio o engenheiro de software deverá se basear no

paradigma de programação adotado (objetos, estruturado ou aspectos).

De maneira geral, os métodos para separação de propriedades envolvem as

seguintes atividades (AKSIT et al. 2001):

· Identificação d e propriedades: seleção de propriedades que o sistema vai

incluir;

· Representação de propriedades separadamente: especificação de propriedades

em unidades ou num conjunto de unidades que concretizam a realização de

cada uma das propriedades; e


· Composição de propriedades: integração de unidades separadas a fim de dar

a elas alguma coerência para formar o conjunto do sistema.

As abordagens tradicionais de desenvolvimento de software (orientação a objetos e

métodos estruturados) f o ram criadas com este princípio geral em mente. Entretanto, elas

possuem limitações no tratamento dos requisitos não-funcionais. Assim, não consideram a

natureza de transversal destas propriedades. Para tentar solucionar essas limitações, foram

propostas algumas abordagens na literatura, tais como: Programação Adaptativa

(LIEBERHERR, 1996), Filtros de Composição (BERGMANS & AKSIT, 2001; BERGMANS

et al., 2001), Separação Multidimensional de Preocupações (TARR et al., 1999; OSSHER &

TARR, 2000) e Programação Orientada a Aspectos (KICZALES et al., 1997). Essas propostas

pertencem a uma área de pesquisa denominada de Separação Avançada de Preocupações

(Advanced Separation of Concerns).

Um modelo genérico para tratar a separação avançada de propriedades1 foi

proposto por Brito & Moreira (2003) e é baseado nas atividades citadas anteriormente

propostas por Aksit (2001), conforme pode ser observado na figura 3.1.

1 o termo preocupações é utilizada na tradução em alguns artigos, porém iremos utilizar propriedades.


FIGURA 2.1 – MODELO DE SEPARAÇÃO AVANÇADA DE PROPRIEDADES. ADAPTADO DE (BRITO &

MOREIRA, 2003).

A seguir segue-se uma breve descrição das tarefas a serem realizadas na Figura

2.1:

· Tarefa 1 – Identificar Concerns2 – a identificação de propriedades é uma tarefa

extremamente importante, pois é acompanhada por um entendimento completo e

exaustivo do sistema por meio da análise da documentação e qualquer outra

informação fornecida pelos stakeholders3 do sistema. Segundo Brito &Moreira

(2003) ainda é uma atividade dependente principalmente da experiência do

engenheiro de software.

· Tarefa 2 – Especificar Concerns – esta tarefa é subdividida em três sub-tarefas:

aplicar a abordagem que melhor especifica cada propriedade; identificar

2 O termo concern é utilizado por Brito & Moreira (2003). Assim, será utilizado apenas nos títulos das tarefas explicitadas por eles. 3 Stakeholder pode ser qualquer pessoa que tem uma influência direta ou indireta no projeto (BRITO & MOREIRA, 2003).


contribuições entre propriedades de tal forma que os conflitos possam ser

detectados e identificar prioridades e inter-relacionamentos.

· Tarefa 2.1 – Especificar concerns usando a melhor abordagem – podemos

utilizar qualquer técnica para a especificação de requisitos. Em certos casos, a

escolha deve ser feita durante a Tarefa 1, especialmente se uma técnica particular

foi usada para auxiliar o processo de elicitação. Se for assim, podemos construir

qualquer modelo ou outra documentação proposta por estas técnicas.

· Tarefa 2.2 – Identificar contribuições entre concerns – o relacionamento de

contribuição entre duas propriedades define a maneira pela qual uma propriedade

afeta o outro. Esta contribuição pode ser colaborativa (ou positiva, quando auxilia

o propriedade afetada) e sua representação é feita por um “+”, ou perigosa (ou

negativa, obstruindo a propriedade afetada) e sua representação é feita por um “-“.

· Tarefa 2.3 – Identificar prioridades e inter-relacionamentos – uma prioridade

proporciona um grau de importância a uma propriedade no sistema. A prioridade

da propriedade é um contexto de dependência, por exemplo, uma mesma

propriedade pode ser classificada com diferentes prioridades pelo stakeholder

dependendo do domínio de negócio. Os inter-relacionamentos fornecem uma lista

de propriedades e suas necessidades.

· Tarefa 3 – Identificar Crosscutting Concerns – uma propriedade está transversal

se precisa de mais de uma outra propriedade, identificado na Tarefa 2.3.

· Tarefa 4 – Compor Concerns – o objetivo desta tarefa é compor todas as

propriedades para formar todo o sistema. Esta tarefa é composta de quatro sub-

tarefas.

· Tarefa 4.1 – Identificar match points – Identificar os pontos onde a composição

será realizada. Um match point indica qual propriedade transversal deve ser

composta com uma dada propriedade.

· Tarefa 4.2 – Identificar conflitos – identificar as situações de conflito entre

propriedades. Para um dado match point precisamos analisar se as propriedades

transversais envolvidas contribuem negativamente para outras quaisquer. Se

contribuírem positivamente não há problema.


· Tarefa 4.3 – Identificar concerns dominantes – Esta sub-tarefa ajuda a resolver

os conflitos identificados na tarefa anterior e é baseado nas prioridades atribuídas.

Se a prioridade atribuída a cada propriedade é diferente, o problema não é tão

difícil de resolver, e a propriedade dominante é aquele com a maior prioridade.

Entretanto, se no mínimo duas propriedades transversais possuem a mesma

prioridade, um trade-off4 devem ser negociado entre os usuários. A identificação

da propriedade dominante é importante para guiar a regra de composição.

· Tarefa 4.4 – Definindo regras de composição – a regra de composição define a

ordem na qual as propriedades devem ser aplicadas em um particular match point.

(BRITO & MOREIRA, 2003) indica o seguinte formato: <concern> <operador>

<concern>. Os operadores irão depender da linguagem a ser utilizada. Esta regra

expressa a ordem seqüencial na qual o aspecto deve ser combinado com a(s)

unidade(s) que ele afeta, ou seja, especifica como o comportamento do aspecto

deve ser aplicado no(s) match point ou ponto(s) de junção.

22..11..33 CCoo mmppoossiiççããoo ddee PPrroopprriieeddaaddeess

Na Figura 2.1 a composição de propriedades é realizada através da Tarefa 4 ( e

suas sub-tarefas), como explicado anteriormente.

Jacobson (2005) argumenta que a composição de aspectos, principalmente se

for feita em um nível mais alto de modelos de pontos de junção não é uma tarefa trivial.

Realizar a composição de aspectos dinamicamente tem seus próprios desafios, tornando

esta tarefa complicada na fase de programação. Porém, isto não implica que a composição

em nível de requisitos seja trivial.

Sem dúvida, são problemas diferentes, mas possuem desafios em ambas as

situações. Na programação pelo menos um modelo estruturado do sistema já está definido

(JACOBSON, 2005). Já na fase de requisitos, a situação é diferente, pois requisitos

tendem a estar em pedaços de textos os quais, geralmente, são difíceis de serem

interpretados e possuem informações ambíguas e incompletas (muitas das vezes).

4 Trade-off não pode ser traduzido literalmente pois perderá o sentido, porém neste contexto se refere a um ponto de equilíbrio ou uma troca, a fim de achar um ponto neutro.


Assim o trabalho de especificação de regras de composição (pointcuts) é muito

mais complicado do que aparenta.

De maneira geral, o paradigma orientado a aspectos complementa paradigmas

anteriores (estruturado e orientado a objetos) em dois sentidos (ELRAD, 2001):

(i) Localizando propriedades transversais em unidades separadas, denominadas de

aspectos; e

(ii) Provendo mecanismos para fazer a composição de propriedades transversais

com as unidades de decomposição do sistema que elas afetam (também

denominadas de unidades base). Para que um aspecto seja combinado com a(s)

unidade(s) que ele afeta, são necessárias algumas informações:

(a) Ponto(s) de junção: indica em que ponto(s) na especificação da(s)

unidade(s) base o comportamento do aspecto deve ser incluído (BRITO

& MOREIRA, 2003);

(b) Regra de composição: expressa a ordem seqüencial na qual o aspecto

deve ser combinado com a(s) unidade(s) que ele afeta (MOREIRA et

al., 2002), ou seja, especifica como o comportamento do aspecto deve

ser aplicado no(s) ponto(s) de junção. As regras de composição mais

comuns são: “antes”, “depois”, e “ao invés de”; Exemplificando:

quando dito que o aspecto de autenticação de senha deve ser aplicado

antes da execução de transações bancárias, o termo antes corresponde a

uma regra de composição e a sentença execução de transações

bancárias corresponde ao ponto de junção (SOUZA, 2004)

Existem quatro possibilidades de especificar a composição entre um aspecto e

unidades base (KERSTEN & MURPHY, 1999):

· Fechada: o aspecto e a unidade base não “têm conhecimento” sobre a

existência um do outro, ou seja, eles não se referenciam diretamente;

· Aberta: aspecto e a unidade base “têm conhecimento” sobre a existência

um do outro, ou seja, eles se referenciam mutuamente;

· Dirigida ao componente: somente o aspecto referencia a unidade base; e

· Dirigida ao aspecto: somente a unidade base referencia o aspecto.


Segundo (SOUZA, 2004) a associação do tipo fechada é a preferencial, visto

que permite a independência tanto das unidades base quanto do aspecto, promovendo,

então, melhor potencial para que os artefatos envolvidos possuam qualidades como

reusabilidade, compreensibilidade e manutenibilidade. A associação do tipo aberta deve

ser evitada, pois resulta em acoplamento entre os dois tipos de artefatos e,

conseqüentemente, compromete o alcance da separação de propriedades e seus benefícios.

Por sua vez, as associações do tipo dirigida ao componente e dirigida ao aspecto,

promovem as qualidades já citadas apenas com relação à unidade base e ao aspecto,

respectivamente.

Ainda segundo (SOUZA, 2004) os tipos de associações mais comuns nas

abordagens orientadas a aspectos são as fechadas e dirigidas ao componente.

22..11..44 AA PP rroogg rraammaaççããoo OOrriieennttaaddaa aa AAssppeeccttooss ee aa LLiinngguuaaggeemm

AAssppeeccttJJ

O termo “programação orientada a aspectos” é atribuído ao grupo de pesquisa

da Xerox PARC liderado por Gregor Kiczales e corresponde a uma técnica de

programação que possibilita a separação de preocupações transversais na implementação

de sistemas (KICZALES et al., 1997).

Essa abordagem denomina de maneira distinta dois tipos de preocupações: as

que conseguem ser adequadamente modularizadas pelos paradigmas estruturado ou

orientado a objetos são chamadas de componentes; e aquelas que não conseguem, ou seja,

as preocupações transversais, são denominadas de aspectos (KICZALES et al., 1997).

Na Programação Orientada a Aspectos, assume-se que existe uma

decomposição dominante do sistema (ex: em classes ou módulos) para os componentes, e

que os aspectos representam outra unidade de decomposição do sistema. Dessa maneira,

componentes são implementados numa linguagem procedural ou orientada a objetos,

enquanto aspectos são codificados em uma linguagem especialmente designada para esse

propósito (SOUZA, 2004). Linguagens orientadas a aspectos utilizam cinco elementos

para permitir a modularização de preocupações transversais (ELRAD et al., 2001):


(i) um modelo de pontos de junção descrevendo os possíveis pontos onde o

comportamento do aspecto pode ser adicionado;

(ii) um meio de identificar esses pontos de junção;

(iii) um meio de especificar o comportamento adicional nesses pontos;

(iv) unidades que encapsulam a especificação dos pontos de junção e as

melhorias comportamentais providas pelo aspecto; e

(v) um mecanismo para combinar o comportamento transversal do aspecto com

o comportamento do(s) componente(s) que ele afeta.

Em resumo, na Programação Orientada a Aspectos, propriedades transversais

são encapsuladas em unidades denominadas aspectos, nas quais são especificados os

pontos de execução nos componentes que a propriedade transversal afetará e o

comportamento/propriedade que devem ser adicionados nesses pontos. Como ilustrado

pela Figura 2.2, o sistema final é formado a partir da combinação de aspectos e

componentes, num processo denominado de weaving.

FIGURA 2.2 - PROCESSO DE COMBINAÇÃO DE ASPECTOS E CLASSES PARA GERAR O SISTEMA. FONTE:

(SOUZA, 2004)

A linguagem AspectJ (KICZALES et al., 2001) é um superconjunto ou uma

extensão da linguagem Java5 (GOSLING et al., 2000) para ser usado na Programação

Orientada a Aspectos. Em uma aplicação orientada a aspectos em AspectJ, os

5 Neste trabalho trataremos exclusivamente da linguagem Java e AspectJ, por ser Java a linguagem de utilizada no desenvolvimento do projeto DiSEN e da ferramenta REQUISITE.

Aspecto

Aspectos

Combinador de aspectos (weaver)

Sistema

Classe

Componentes


componentes são implementados usando a sintaxe padrão de Java, e os aspectos são

implementados usando uma sintaxe específica de AspectJ. Essa linguagem utiliza um

processador de aspectos — denominado de weaver — para combinar o código do aspecto

com o código dos componentes e conseqüentemente produzir o sistema executável. Após a

compilação e o processo de weaving, o código objeto gerado pode ser executado em

qualquer máquina virtual Java.

Em AspectJ, o código referente a uma propriedade transversal é especificado

numa unidade de codificação denominada aspect (veja Figura 3.3). Dentro da unidade do

tipo aspect, o código relacionado à propriedade transversal utiliza construtores lingüísticos

especiais:

· o construtor pointcut é utilizado para capturar ou identificar pontos de

junção no fluxo do programa sobre os quais o aspecto atua. Exemplos de

possíveis pontos de junção incluem inicialização de objetos, chamadas de

métodos e acesso a campos;

· advices são blocos de código no quais devem ser definidos as regras de

composição e o comportamento a ser executado pelo aspecto. Para

determinar as regras de composição nos pontos de junção identificados,

utilizam-se as regras de composição before, after e around. Essas regras

indicam que o comportamento do aspecto deve ser executado,

respectivamente, antes, após, ou ao invés de cada ponto de junção definido

pelo pointcut associado.

· inter-type declarations possibilita que classes presentes no sistema sejam

modificadas estruturalmente: (i) acrescentando métodos, atributos e classes

internas; e (ii) alterando a hierarquia de herança de classes e interfaces.


FIGURA 2.3 – ESTRUTURA DE UMA ENTIDADE ASPECT EM ASPECTJ.

ADAPTADO DE (SOUZA, 2004).

Conforme ilustra a Figura 2.3, além dos construtores próprios de AspectJ, uma

unidade do tipo aspect pode conter membros de dados e métodos, assim como uma classe.

A Figura 2.4 apresenta um exemplo de código em AspectJ que implementa um

aspecto de logging para rastrear a execução de métodos. A princípio, é definido um ponto

de junção loggedMethod (linha 3), incluindo todas as chamadas de métodos.

Entre a linha 5 e a 11 são definidos dois advices para que sejam exibidas

mensagens imediatamente antes da execução e imediatamente após o retorno do ponto de

junção.

FIGURA 2.4 - EXEMPLO DE CÓDIGO EM ASPECTJ. ADAPTADO DE (SOUZA, 2004).

Para que se compreenda o processo de desenvolvimento de sistemas utilizando

a orientação a aspectos é preciso conhecer os conceitos de algumas das abordagens de

desenvolvimento utilizadas na Fase de Requisitos.

Atributos

Métodos

Pointcuts ou pontos de corte

Advices ou informações

Declarações inter-type

Parte comum a

classes

Construtores específicos de AspectJ

1 public aspect Logging { 2 3 Pointcut LoggedMethod(): call (* *(..)); 4 5 Before(): loggedMethod() { 6 System.out.println(“--ANTES DA EXECUÇÃO DA CHAMADA DE UM MÉTODO --“); 7 } 8 9 after(): loggedMethod() { 10 System.out.println(“--DEPOIS DO RETORNO DA CHAMADA DE UM MÉTODO --“); 11 } 12 }


33..22 FFaassee ddee RReeqquuiissiittooss

A abordagem da Engenharia de Requisitos Orientada a Aspectos (AORE), tem

como objetivo o tratamento sistemático e modular, na argumentação, composição e

subseqüente rastreamento das propriedades transversais funcionais e não funcionais

através de uma adequada abstração, representação e mecanismos de composição próprios

para o domínio da engenharia de requisitos (CHITCHYAN et al, 2005a).

A seguir serão apresentadas as principais abordagens existentes para esta fase,

que servirão de ponto de partida para a definição da nova abordagem, a ser apresentada no

presente trabalho.

22..22..11 AAbboo rrddaaggeemm VViieewwppoo iinntt

A abordagem da Engenharia de Requisitos Orientada a Viewpoint considera a

informação do problema relacionado a partir de vários agentes ao ser estabelecido o que é

requerido para a resolução de determinado problema, os quais podem ter perspectivas

incompletas e igualmente válidas (CHITCHYAN et al, 2005a).

A combinação entre agentes e as visões dos agentes é chamado de viewpoint.

(CHITCHYAN et al, 2005b). Em (SOMMERVILLE & SAWYER, 1998) é apresentado o

PREView, sendo uma abordagem não orientada a aspectos, onde é uma generalização da

noção de metas, que inclui tanto as metas organizacionais que restringem o sistema como

o processo a ser analisado. Esta abordagem não identifica qualquer propriedade transversal

separadamente: todas elas são tratadas como parte de um ponto de vista. Embora os pontos

de vista ou viewpoints possam sobrepor e transpor as outras, esta é tratado como questão

de resolução de inconsistência, mais do que um problema de separação de propriedades.

Em (RASHID et al 2002) esta abordagem recebeu o nome de AORE, porém

como este conceito é geral, está sendo utilizado o nome da ferramenta (ARCADE) que

utiliza esta abordagem, assim como no trabalho apresentado em (CHITCHYAN et al,

2005a).

Em (RASHID et al, 2003) é apresentada uma instanciação do modelo geral do

processo de requisitos, conforme pode ser observado na Figura 3.5. Esta instanciação é

similar ao utilizado no PREview. Entretanto, no Arcade, seu objetivo está em modularizar

e compor propriedades no nível de requisitos e não apenas na produção de um documento

de especificação de requisitos.


Podemos observar que a Figura 2.5 é muito similar a Figura 2.1. Na verdade, a

Figura 2.5 foi uma adaptação e refinamento desta última. Suas fases e descrições são

similares à apresentada na Figura 2.1.

FIGURA 2.5 – MODELO DE PROCESSO AORE. ADAPTADO DO (RASHID ET AL, 2003)

(RASHID et al, 2002) definem que, inicialmente, é necessário identificar

requisitos funcionais e propriedades, porém a ordem não é definida pelo modelo: ela

Identificar concerns

Identificar requisitos

Especificar concerns

Especificar requisitos

Relacionar concerns e requisitos

Identificar aspectos candidatos

Definir regras de composição

compor aspectos candidatos e requisitos

elaborar tabelas de contribuição

atribuir medidas para aspectos conflitantes

Resolver conflitos

composição

Gerenciar conflitos

especificar dimensões do aspecto

Revisar especificações de requisitos


dependerá da interação entre os engenheiros e os usuários do sistema, mesmo porque esta

atividade ainda é uma atividade que depende da experiência do engenheiro de requisitos.

Após esta fase, na qual f o ram identificados os requisitos e propriedades

pertinentes ao domínio do sistema a ser desenvolvido, deve-se relacionar as propriedades a

requisitos funcionais em uma matriz, de acordo com a tabela 2.1.

TABELA 2.1 – RELACIONANDO PROPRIEDADES COM REQUISITOS DOS STAKEHOLDERS. ADAPTADO DO

(RASHID ET AL, 2003).

Requisitos dos Stakeholders Propriedades

R1 R2 .... Rn

propriedades 1 X X

propriedades 2 X

...

propriedades n X X

Observando a matriz formada pela Tabela 2.1 podemos constatar quais

propriedades cruzam com os módulos encapsulados pelos requisitos dos stakeholders.

Estas propriedades são qualificadas como aspectos candidatos.

Segundo (SOUZA, 2004), um aspecto candidato é quando uma propriedade

pode influenciar ou restringir mais de um requisito funcional.

Rashid et al (2003) argumenta que após serem identificados os aspectos

candidatos são necessários detalhar as regras de composição. Estas regras operam na

granularidade dos requisitos individualmente e, não apenas nos módulos que as

encapsulam. Assim é possível especificar como um requisito aspectual influencia ou

restringe o comportamento de um conjunto de requisitos não aspectuais nos vários

módulos. Ao mesmo tempo, aspectos trade-offs podem ser observados em uma

granularidade menor. Isto exclui a necessidade de negociações entre stakeholders para os

casos onde podem existir um aparente trade-off entre dois ou mais aspectos mas de fato

requisitos diferentes e isolados podem ser influenciados por eles. Também facilita a

identificação de conflitos individuais dos requisitos aspectuais com respeito a qual

negociação deve ser cumprida e o equilíbrio estabelecido.


A próxima atividade é responsável por analisar aspectos candidatos em mais

detalhes, identificando conflitos entre eles e estabelecendo prioridades. Para esta atividade

deve ser feita uma tabela de acordo com o exemplo fornecido pela tabela 2.2.

TABELA 2.2 – MAPEAMENTO ENTRE ASPECTOS CANDIDATOS. ADAPTADO DO (RASHID ET AL, 2003).

Aspecto 1 Aspecto 2 ... Aspecto n

Aspecto 1 +

Aspecto 2 _

...

Aspecto n

Na tabela 2.2 podemos observar que o Aspecto 1 contribui positivamente (+)

com o Aspecto 2 e o Aspecto 2 contribui negativamente (-) com o Aspecto n. As células

em branco significam que não tem contribuição

Após preencher esta tabela devemos atribuir pesos para os aspectos que

contribuem negativamente com outro em relação ao conjunto de requisitos do usuário.

Cada peso é um número real em um intervalo de 0 a 1 e representa a prioridade de um

aspecto em relação ao conjunto de requisitos dos stakeholders.

Após atribuir os pesos aos aspectos devem-se resolver os conflitos com os

stakeholders, usando a priorização acima descrita para auxiliar a comunicação.

Por fim, deve-se especificar o impacto de aspectos candidatos em termos de

duas dimensões: mapeamento e influência. A dimensão de mapeamento especifica como

cada aspecto candidato será manipulado nos estágios seguintes do desenvolvimento. Nesta

dimensão o aspecto candidato pode ser mapeado em uma função, decisão arquitetural ou

num aspecto.

Por outro lado, a dimensão de influência estabelece quais os pontos do ciclo de

desenvolvimento que o aspecto candidato afetará. A tabela 2.3 mostra um exemplo de

saída dessa atividade.


TABELA 2.3 – EXEMPLO DE UMA ESPECIFICAÇÃO DA DIMENSÃO DO ASPECTO. FONTE: (RASHID ET AL, 2002).

Aspecto Candidato Influência Mapeamento

Compatibilidade Especificação, arquitetura, design, evolução Função

Tempo de Resposta Arquitetura, design Aspecto

Restrições Legais Especificação Função

Corretude Especificação, design Função

Segurança Arquitetura, design Aspecto

Disponibilidade Arquitetura Decisão

Sistema Multi-usuário Arquitetura, design Aspecto

Por sua vez, Moreira et al. (2002), Araujo et al. (2002) e Brito & Moreira

(2003) usam uma instância simplificada do modelo AORE baseada em UML (BOOCH et

al., 1999). S ouza ( 2004) detalha este trabalho como sendo uma extensão do processo

anterior e Chitchyan et al ( 2005b) apresentam como sendo uma extensão da abordagem

viewpoint e apenas cita os trabalhos. Porém, vamos tratar este trabalho em separado, pois

apesar de se utilizar do modelo AORE detalhado anteriormente possui algumas

características diferentes.

22..22..22 AAbboo rrddaaggeemm AAOORREE uuttiilliizzaannddoo UUMMLL

Esta abordagem teve início em Moreira et al. (2002), Araújo et al. (2002) e

Brito & Moreira (2002) e é composta de três atividades principais, descritas a seguir:

a) Identificar concerns6 - em (BRITO & MOREIRA, 2002) esta atividade é limitada

a identificar os requisitos do sistema e selecionar os requisitos de qualidade que

são relevantes para o domínio da aplicação. Não especifica como identificar os

requisitos, especificam ainda que esta atividade deve identificar todas as

propriedades do sistema, ou seja, os requisitos funcionais e não-funcionais. Os

autores dizem ainda que diferentes técnicas podem ser utilizadas para identificar os

requisitos e particularmente escolheu a técnica de casos de uso. Porém, salientam

que a identificação de propriedades funcionais e não funcionais irá depender da

6 O termo concern foi utilizado apenas no título da atividade, porém será utilizado propriedade em outras oportunidades.


visão dos stakeholders em relação ao sistema e à dinâmica de comunicação entre

os desenvolvedores e clientes.

b) Especificar concerns e identificar q u a is d e l e s são transversais ( aspectos

candidatos) – esta atividade pode ser dividida em duas partes principais:

b.1) especificar requisitos funcionais usando a abordagem de casos de uso; e

b.2) descrever atributos de qualidade usando templates especiais (Tabela 2.4) e

identificar aqueles que atravessam os requisitos funcionais (atributos de qualidade).

TABELA 2.4 – TEMPLATE PARA ATRIBUTOS DE QUALIDADE. FONTE: (BRITO & MOREIRA, 2002)

Nome Nome do atributo de qualidade

Descrição Descrição sucinta

Focus O atributo de qualidade pode afetar o sistema (produto final) ou

o desenvolvimento do processo

Fonte Fonte da informação (documentos, stakeholders)

Decomposição Os atributos de qualidade podem ser decompostos em outros

mais simples. Quando todos (sub) atributos de qualidade são

necessários para obter o atributo de qualidade, temos um

relacionamento AND, caso contrário, temos um relacionamento

OR.

Prioridade Expressa a importância do atributo de qualidade para os

stakeholders. A prioridade pode ser MAX, HIGH, LOW e

MIN.

Obrigação Pode ser opcional ou obrigatória.

Influencia Atividades do processo afetadas pelos atributos de qualidade

Onde Lista dos atores influenciados pelos atributos de qualidade e

uma lista de modelos (casos de uso, diagramas de seqüência)

que necessitam do atributo de qualidade.

Requisitos Requisitos descrevendo o atributo de qualidade.

Contribuição Representa como o atributo de qualidade afeta outros atributos.

A contribuição pode ser positiva (+) ou negativa (-).


b.3) propor um conjunto de modelos para representar a integração de atributos de

qualidade transversais e requisitos funcionais.

Para Brito & M oreira (2003) esta atividade deve especificar propriedades e

finalizar pela identificação dos aspectos candidatos. As propriedades funcionais são

especificadas através de um conjunto de cenários e diagramas de seqüência. As

propriedades não funcionais através de um template especial, conforme verificado na

Tabela 2.5. (muito parecido com o trabalho anterior em (BRITO & MOREIRA,

2002)).

TABELA 2.5 – TEMPLATE PARA REQUISITOS NÃO FUNCIONAIS. FONTE: (BRITO & MOREIRA, 2003)

Nome Nome da propriedade não funcional

Descrição Descrição sucinta

Prioridade Expressa a importância da propriedade. A prioridade pode ser

Muito Importante, importante, médio, baixo e muito baixo.

Decomposição As propriedades podem ser decompostos em outros mais

simples. Onde Lista de modelos e seus elementos (casos de uso, classes,

diagramas de seqüência) que necessitam da propriedade

Requisitos Requisitos descrevendo a propriedade

Contribuição Representa a maneira como uma propriedade afeta outras

propriedades. A contribuição pode ser positiva (+) ou negativa

(-).

Brito & Moreira ( 2003) deixam claro que as informações na tabela (Tabela 2.5)

devem ser preenchidas gradativamente, pois parte de uma propriedade pode ser

dependente da especificação de outra.

Ambos os trabalhos deixam claro que a identificação de propriedades transversais

deve ser definida nas linhas “Onde” e “Requisitos”. Estas serão o s aspectos

candidatos.

c) Compor aspectos candidatos com outros concerns – o objetivo é integrar os

aspectos candidatos com outras propriedades que atravessam para obter todo o


sistema. Brito & Moreira (2002) especificam alguns passos para guiar esta

composição:

c.1) identificar como cada aspecto candidato afeta a propriedade que atravessa;

c.2) identificar os match point, baseados na linha”Onde” da Tabela 2.4 e 2.5;

c.3) Identificar conflitos entre os aspectos candidatos baseados na linha

“Contribuição” da Tabela 2.4 e 2.5;

c.4) identificar o aspecto dominante, baseado na linha “Prioridade” da Tabela 2.4 e

2.5; e

c.5) definir a regra de composição, baseado nos quatro passos acima.

Para o passo (c.1) foi adotado os conceitos de overlap, override, wrap. Overlap é

quando o aspecto candidato é aplicado antes ou depois da propriedade que atravessa.

Override é quando o aspecto candidato sobrepõe a propriedade que atravessa, ou seja,

o comportamento descrito pelo aspecto candidato substitui o comportamento definido

pela propriedade. Wrap é quando o aspecto candidato encapsula a propriedade que

atravessa, ou seja, o comportamento descrito pela propriedade afetada está envolvido

pelo comportamento descrito pelo aspecto candidato.

Para exemplificar graficamente o passo (c.1) é utilizado um diagrama de casos

de uso, Figura 2.6.


Proprietário do Veículo

Motorista

cruzar pedagio

sair da rodovia

entrar na rodovia

tempo de resposta

pagar fatura

segurança

registrar veiculo

Banco

<<overlapBy>>

<<overlapBy>>

<<wrappedBy>>

<<wrappedBy>>

<<wrappedBy>>

<<wrappedBy>>

FIGURA 2.6 – EXEMPLO DE CASO DE USO COM ASPECTO CANDIDATO – PASSO (C .1) . ADAPTADO DO (BRITO & MOREIRA, 2003).

Um exemplo de composição em diagrama de caso de uso, usando esses

operadores de composição num sistema de cobrança de pedágio é mostrado na Figura 3.6.

Nesse exemplo, de Brito & Moreira (2004), o aspecto de segurança afeta os casos de uso

Pagar fatura e Registrar veículo com o operador overlap; e o aspecto de tempo de

resposta afeta os casos de uso Registrar veículo, Entrar na rodovia, Sair da rodovia e

Cruzar pedágio. Entretanto, não é indicado em que pontos do fluxo dos casos de uso esses

aspectos devem ser aplicados; nem tão pouco é especificado como as preocupações de

segurança e tempo de resposta serão operacionalizadas no sistema de cobrança de pedágio.

No trabalho anterior, Brito & Moreira (2002) i ndicam que o aspecto de

segurança é decomposto em duas sub-propriedades: confidenciabilidade e integridade,

podendo demonstrar isso através de um diagrama de composição de sub-propriedades,

conforme a Figura 2.7.


FIGURA 2.7 – USE CASE DE OVERLAP DO ASPECTO SEGURANÇA. ADAPTADO DO (BRITO & MOREIRA,

2002).

Para o Passo (c.2) – A identificação de match points é feita utilizando uma

tabela entre atores e casos de uso (Tabela 2.6). Para cada intersecção da célula listamos os

aspectos candidatos que podem ser afetados tanto pelos atores quanto pelos casos de uso.

Esta tabela servirá para identificar os aspectos conflitantes.

Proprietário do Veículo

pagar fatura registrar veiculo

Banco

<<after>>

<<before>>

Confidenciabilidade Integridade

Segurança

AND


TABELA 2.6 – IDENTIFICAÇÃO DE MATCH POINTS. ADAPTADO DO (BRITO & MOREIRA, 2003).

Casos de Uso

Atores Registrar

veículo

Pagar fatura Entrar rodovia Sair rodovia Cruzar pedágio

Banco T e m p o d e resposta, segurança, corretude.

(A)

Compatibilidade, segurança.

(B)

Proprietário

do veículo

T e m p o d e resposta, segurança, corretude.

(C)

Regras l ega i s , segurança.

(D)

Motorista Compatibilidade, tempo de resposta,

corretude.(E)

Compatibilidade, regras legais,

corretude.(F)

Compatibilidade, t e m p o d e resposta,

corretude.(G)

Na Tabela 2.6 nomeamos as interseções das células em A, B, C, D, E, F e G.

Em (A), por exemplo, temos três aspectos candidatos, Para simplificar vamos considerar

apenas os dois primeiros. Para verificarmos se existe um conflito que deve ser

considerado, temos que olhar a especificação dos dois aspectos, Tabela 2.4 ou Tabela 2.5

na linha “Contribuição”, e verificar se eles contribuem negativamente para o outro, esta

atividade seria o Passo (c.3).

Para tentar resolver uma provável situação entre aspectos conflitantes é

necessário verificar a prioridade de cada aspecto envolvido. Para isso, deve-se observar a

linha “Prioridade” na Tabela 2. 4 o u 2.5. No caso do exemplo acima, poderíamos

classificá-los como “muito importante”, logo teríamos as mesmas prioridades. Assim,

neste caso (quando os aspectos possuem a mesma prioridade) precisamos negociar um

trade-off com o cliente ou determinar o aspecto dominante (Passo c.4).

Vamos supor que o ator Banco decida que o aspecto candidato dominante seja

a Segurança. No Passo (c.5) vamos definir as regras de composição usando a informação

obtida até agora.


Assim, a regra de composição da célula (A) poderia ficar definida como se

segue:

Segurança.confidenciabilidade overlaps.before RegistrarVeiculo;

TempoResposta wraps RegistrarVeiculo;

Segurança.integridade overlaps.after RegistrarVeiculo

FIGURA 2.8 – EXEMPLO DE REGRA DE COMPOSIÇÃO. FONTE: (BRITO & MOREIRA, 2003).

A regra de composição da Figura 2.8 expressa a ordem seqüencial na qual cada

aspecto candidato pode ser composto. Assim, podemos definir qual a sub-propriedade

deve ser satisfeito antes do outro. No exemplo acima, vemos que a confidenciabilidade

(descrita como segurança.confidenciabilidade) deve ser satisfeita antes do caso de uso

Registrar Veículo. Os match points identificados na Tabela 2.6 devem ser resolvidos de

forma similar.

22..22..33 AAbboo rrddaaggeemm GGooaallss

A abordagem GOALS ou metas utiliza alguns conceitos relacionados à

diagramação do modelo i* (LIU et al, YU & MYLOPOULOS apud YU et al, 2004). O

principal propósito desta abordagem é a identificação de aspectos através do

relacionamento entre metas funcionais e não-funcionais.

Yu et al (2004) apresentam um trabalho fundamentado na análise do modelo de

metas (Giornini apud AORE, 2005). O modelo gráfico utilizado é chamado de V-Graph

(Figura 2.9).


Hard goals (objetivos ou metas) softgoals

Tarefas

FIGURA 2.9 – O GRÁFICO V-GRAPH E SUA COMPOSIÇÃO. FONTE: TRADUZIDO DE (AORE, 2005).

O V-Graph apresentado na Figura 2.9 apresenta no topo dois vértices, hard

goals e soft goals, que respectivamente são os requisitos funcionais e não funcionais em

termos de modelo de metas. A representação é baseada no modelo proposto por

(MYLOPOULOS et al, 1992).

FIGURA 2.10 – O GRÁFICO V-GRAPH E SUA REPRESENTAÇÃO. FONTE: TRADUZIDO DE (YU ET AL, 2004).

Na Figura 2.10 vemos a representação gráfica de Objetivo/Meta (goals ou

requisitos funcionais), SoftGoal (requisitos não funcionais) e Tarefas (task).

Existe uma relação de contribuição entre as Task e os Goal e SoftGoal, ou seja,

uma tarefa contribui (de alguma forma) para que os requisitos funcionais ou não

funcionais sejam satisfeitos. De forma similar existe uma correlação entre Goal e SofGoal.

Objetivo/Meta

Tarefa

SofGoal Correlação

Contribuição Contribuição

Contribuições e correlações


TABELA 2.7 – CONTRIBUIÇÃO E CORRELAÇÃO. ADAPTADO DO (YU ET AL, 2004).

Tipo de Link e ou faz ajuda prejudica Quebra

Contribuição Y Y Y Y Y Y

correlação N N Y Y Y Y

A Tabela 2.7 demonstra os tipos de relação que podem existir entre os

elementos do V-Graph, onde podemos observar os tipos de link e as relações que podem

existir entre Task , Goal e SoftGoal.

O processo de construção e descoberta de aspectos consiste principalmente no

refinamento sistemático do V-Graph. O processo termina quando todos os objetivos

(goals) principais e todos os softgoals são satisfeitos. Nesta etapa estamos aptos a

identificar aspectos candidatos através das tarefas que possuem um alto fan-in7.

FIGURA 2.11 – A VISÃO GERAL DA ABORDAGEM GOAL. FONTE: TRADUZIDO DE (YU ET AL, 2004).

7 Fan-in – número de módulos que chamam (ou usam); Fan-out – número de módulos que são chamados (ou

usados) . Fonte: Constantine e Yourdon (1979)

decomposto

Lista de objetivos

softgoals correlacionado Objetivo principal

Objetivos softgoals

tarefas

Resolver conflitos

Não

Objetivos

tarefas

Sem conflitos

Sim

Não

Consistente

Sim

Não

Satisfeito

Sim

Correlação

decomposição

Objetivos softgoals

tarefas Lista de aspectos

Aspectos

V-Graph

softgoals


A Figura 2.11 mostra uma visão do processo de modelagem do V-Graph.

Inicialmente um conjunto de objetivos, incluindo um ou mais objetivos funcionais e

alguns não funcionais, são listados. Depois o engenheiro de requisitos e o especialista de

domínio decompõe os objetivos (metas ou goals) e softgoals em sub-objetivos (submetas

ou subgoals) e subsoftgoals ou tarefas, e correlaciona os objetivos/tarefas da perspectiva

funcional para o softgoal operacionalizações8 de um não funcional. O refinamento do

processo pode ser sem deteriorações e os conflitos podem ser resolvidos através de uma

análise formal dos objetivos (goals), até que os objetivos (goals) e os softgoals estejam

satisfeitos.

Assim como Yu et al (2004), Martinez et al (2004) utilizam a abordagem

GOALS. Contudo, o enfoque baseia-se nos padrões ISO/IEC 9126 como ponto de partida

para estabelecer metas e requisitos; e as recomendações IEEE 830-1998 (IEEE, 1998) para

a definição de especificação de requisitos. O principal argumento utilizado por

MARTINEZ et al é que a utilização dos padrões de qualidade ISO/IEC 9126 facilitam a

identificação dos requisitos não funcionais e, por conseqüência, a identificação das metas

a serem utilizadas no sistema a ser desenvolvido.

A norma ISO/IEC 9126 (ISO, 1994), utilizada por MARTINEZ et al. define

um conjunto de critérios ou características desejáveis referentes ao software e sua

estrutura. Esta norma foi definida para os documentos técnicos durante o último encontro

Internacional do SC7, em junho/1994 e possui 3 ramificações: ISO/IEC 9126-1 -

Características e sub-características de qualidade, ISO/IEC 9126-2 - Métricas externas ,

ISO/IEC 9126-3 - Métricas internas.

A Tabela 2.8 apresenta as características de qualidade ISO/IEC 9126.

8 Operacionalizações se referem a um conjunto de tarefas (tasks) (AORE, 2005).


TABELA 2.8 – CARACTERÍSTICAS DE QUALIDADE ISO/IEC 9126.

ADAPTADO DO (MARTINEZ ET AL, 2004).

Tipo de qualidade Característica Sub-característica

Adequação; Acurácia; Interoperabilidade; Conformidade;

funcionalidade

Segurança de acesso. Maturidade; Tolerância a falhas Recuperabilidade Confiabilidade

Flexibilidade

Inteligibilidade; Apreensibilidade Operacionabilidade

Atratividade

Usabilidade

Flexibilidade Comportamento em relação ao tempo Comportamento em relação aos recursos

Eficiência

flexibilidade Analisabilidade Modificabilidade Estabilidade Testabilidade

Manutenibilidade

Flexibilidade Adaptabilidade Capacidade para ser instalado Conformidade Capacidade para substituir

Qualidade do produto de

software

Portabilidade

Flexibilidade Efetividade Produtividade Segurança

Qualidade em Uso

Satisfação

A abordagem de (MARTINEZ et al, 2004) é útil ao se definir um ponto de

partida para os requisitos não funcionais, porém, não considera o trabalho elaborado por

Yu et al (2004), que também explora a Abordagem Goals. Além disso, argumenta que as

outras propostas existentes (RASHID et al, 2002) (BRITO et al, 2004) não oferecem ao

analista um framework o qual possa auxiliar a identificação de propriedades do sistema,


além de fazerem uma distinção entre requisitos funcionais e não-funcionais através do

emprego de diferentes técnicas para descrever os tipos de requisitos.

Neste trabalho, a autora acredita ser necessária uma diferenciação dos tipos de

requisitos, uma vez que são tratados de forma diferente, assim como no trabalho de

Martinez (2004). Porém sem esquecermos que aspectos podem ser requisitos funcionais.

Este é um ponto que a abordagem de Goals não possui uma definição mais clara, pois

apresenta aspectos como sendo os requisitos não-funcionais, argumentando que em sua

maioria o são.

22..22..44 AAbboo rrddaaggeemm CCoomm CCaassooss ddee UUssoo

A abordagem dirigida a casos de uso provê um método para desenvolver

aplicações através da concentração na realização das propriedades dos stakeholders.

Jacobson & NG (2005) argumenta que os casos de uso são transversais por natureza, uma

vez que sua realização pode afetar outras classes.

A principal dificuldade estava em manter as propriedades transversais

separadas durante todo o processo, porém isso foi conseguido através do conceito de casos

de uso slices (que veremos mais a seguir).

Seu método consiste em realizar a atualização do modelo continuamente

durante o processo.

FIGURA 2.12 – ATUALIZAÇÃO DOS MODELOS NO DESENVOLVIMENTO . ADAPTADO DE (JACOBSON &

NG, 2005).

A abordagem identifica dois tipos de propriedades transversais: peers e

extensions. Os do tipo peers não precisam um do outro para sua existência, podendo ser

Especificando casos de uso

Analisando casos de uso

Design e Implementando casos de uso

atualizações atualizações atualizações

Modelo de

casos de uso

Modelo de

análise

Modelo de

design

Modelo de

implementação


desenvolvidos sistemas em separado para cada um deles, como por exemplo, transferência

de fundos, reserva de quarto e check-in. Porém, quando começamos a implementar os

peers no mesmo sistema, encontramos sobreposições significantes entre eles.

FIGURA 2.13 – EFEITOS DE DISPERSÃO E ENROLAÇÃO QUANDO REALIZAMOS PEERS. ADAPTADO DE

(JACOBSON & NG, 2005).

A limitação em manter os do tipo peers separados causam dois efeitos

conhecidos na linguagem aspectos como enrolação9 e dispersão10. Na enrolação podemos

encontrar um componente que contem a implementação para satisfazer outros

componentes, ou seja, um caso de uso tipo peers possui na sua realização uma alteração ou

implementação de um comportamento de uma outra classe (s). Na Figura 2.13 observamos

que o componente Quarto está envolvido na realização de duas diferentes propriedades.

Na dispersão podemos encontrar códigos que realizam uma propriedade em particular que

está espalhado através de múltiplos componentes. Na Figura 2.13 observamos que a

realização de Check in Clientes impõe comportamento adicional em três outros

componentes.

Um outro tipo de propriedade transversal é chamado de extensions. Os

extensions são componentes que definimos no topo da base, representam serviços ou

características adicionais. Embora seja natural descrever a base (ou o caso de uso base)

separada da extensão, existe um problema quando implementamos a extensão.

9 Tradução literal de tangling. 10 Tradução literal de scattering.

Propriedades

Reserva de Quarto

Check in Clientes

Check out Clientes

Componentes

Tela do cliente

Reserva quarto

reserva

Check in

Tela staff

Check out

quarto


FIGURA 2.14 – EXEMPLO DE EXTENSÃO. ADAPTADO DE (JACOBSON & NG, 2005).

Na figura 2.14 observamos que a extension é inserida de forma intrusiva (como

é conhecida na linguagem aspectos) no código base. Este fragmento de código que chama

a extension é conhecido como pontos de extensão11.

Nesta abordagem são utilizados alguns conceitos da linguagem AspectJ, como

pointcuts, que identificam um ponto de execução no código base e advice, que descrevem

o comportamento adicional que será executado ao chegar neste ponto.

Nas Figuras 2.13 e 2.14 fica evidente a necessidade de preservar a separação de

propriedades através do design e implementação, para evitar os problemas de dispersão e

enrolação já citados. Assim, é necessário colecionar a especificação dos casos de uso

durante o design em uma unidade modular, denominada use case slice12. Cada use case

slice possui partes de classes, operações, e assim por diante, que especificam o caso de uso

no modelo (Jacobson & Ng (2005) argumentam que deve ser feito um caso de uso slice

para cada caso de uso do sistema).

Na verdade, quando realizamos o caso de uso, identificamos classe, atributos,

operações e relacionamentos destas classes. Algumas destas classes e suas características

são específicas da realização do caso de uso, outras são necessárias, porém são de outros

casos de uso. Cada use case slice contém a especificação da realização do caso de uso em

um modelo. A parte genérica e reusável são mantidas em casos de uso específicos não

slices. Todos estes slices são então agrupados para formar todo o modelo de design.

11 Tradução literal de extension points. 12 A tradução para o termo utilizado ficaria: pedaços de casos de uso. Porém iremos utilizar o termo em inglês.

Base Extension

Reserva

de Quarto

Lista de

Espera

Fragmento de código adicionado para chamar o

componente de lista de espera


Camada

aplicação

Camada

domínio

Estrutura casos de uso Estrutura de elementos

composição

composição

FIGURA 2.15 – ESTRUTURA DOS ELEMENTOS E CASOS DE USO SLICES. ADAPTADO DE (JACOBSON & NG, 2005).

Na Figura 2.15 podemos observar que a estrutura dos elementos é apenas uma

forma de identificar onde os elementos residem no modelo. Tratamos estes elementos,

como classes, como caixas vazias. Seu conteúdo (comportamento) será preenchido através

dos casos de uso slices através do mecanismo de composição.

Ou seja, os casos de uso slice não contêm a classe completa, possui apenas

parte delas, chamadas de extensão da classe. As extensões da classe contêm apenas as

características necessárias para concretizar o caso de uso.

FIGURA 2.16 – COMPOSIÇÃO DA REALIZAÇÃO DE CASOS DE USO PEER COM CASOS DE USO SLICES.

ADAPTADO DE (JACOBSON & NG, 2005).

Casos de Uso

Reserva Quarto

Check in

Check out

Reserva Quarto +Check in + Check out

Comportamento da extensão da classe específico da realização do caso de uso

slices

Reserva Quarto

Check in

Check out

Tela cliente

Tela Staff

Reserva Quarto

Check in

Check out

Reserva Quarto Classes


A figura 2.16 demonstra um exemplo dos casos de uso base e seus slices, com

as partes das classes e onde elas são atualizadas.

Jacobson & Ng (2005) também argumentam que a representação tradicional de

casos de uso pode não ser clara o suficiente quando queremos especificar as sub-rotinas ou

extensões existentes no fluxo.

FIGURA 2.17 – REPRESENTAÇÃO DE CASOS DE USO. ADAPTADO DE (JACOBSON & NG, 2005).

Embora a representação (B) da Figura 2.17 seja mais clara, pois especifica os

fluxos existentes, não possui ferramenta case para construí- la.

A representação dos requisitos não-funcionais é realizada através de um caso

de uso especial chamado de perform transaction e os requisitos funcionais (os tradicionais

e usuais) chamamos de casos de uso de aplicação.

FIGURA 2.18 – ESTRUTURANDO CASOS DE USO DE INFRA-ESTRUTURA. ADAPTADO DE (JACOBSON &

NG, 2005).

A Figura 2.18 demonstra a utilização de um exemplo de casos de uso de infra-

estrutura (não funcionais). Apesar dos requisitos não-funcionais serem tratados como

extends, eles fazem parte de um caso de uso único, o < perform transaction> que é

requisitado para executar os requisitos não-funcionais.

Reserva de Quarto

Reserva de Quarto

Flows {basic} Reserva quarto {alt}submissão duplicada

{sub}checar custo do quarto (A) (B)

<ator><perform transaction>

tratar autorização

realizar auditoria transações

rastrear preferências

<<extend>>

<<extend>>

<<extend>>


Ao lidar com um requisito de tempo de resposta de 2 segundos, por exemplo,

devemos modelar e expressar este tipo de requisito como declarações na seção especial do

use case <perform transaction>, como demonstra a Figura 2.19.

FIGURA 2.19 – A ESPECIFICAÇÃO DO CASO DE USO <PERFORM TRANSACTION>. ADAPTADO DE

(JACOBSON & NG, 2005).

Souza (2004) argumentou em seu trabalho que nesta abordagem não se podia

manter a separação de propriedades durante o ciclo de vida do processo, sendo ineficiente.

Porém, seu trabalho não incluiu o trabalho atual do Jacobson & Ng (2004), pois sua

publicação foi posterior a dissertação de Souza. Assim, com o ultimo trabalho de Jacobson

Especificação de Caso de Uso: <perform transaction> Fluxo Básico O caso de uso começa quando um ator instancia a execução de uma transação para visualizar valores de uma instância de uma entidade. 1. O sistema indica a instância do ator que identifica a instância da entidade desejada. 2. A instância do ator entra com valores e submete sua requisição. 3. O sistema resgata a instância da entidade (seus dados) e mostra os valores. 4. O caso de uso termina. Fluxo alternativo A1. Controle de Acesso Se no passo 3 do fluxo básico a requisição requer autorização, o sistema checa os direitos da instancia do ator.

1. Se a instancia do ator não possui direitos de acesso a requisição é rejeitada. O caso de uso termina.

2. Caso contrario, o caso de uso continua. A2. Preferência do Usuário No passo 1 do fluxo básico, se a prioridade principal é definida, o sistema carrega a preferência e usa aqueles valores como padrão para a requisição da instancia do ator. O caso de uso reinicia. No passo 2 do fluxo básico, se o usuário indica que o valor submetido será usado como padrão, o sistema armazena como uma preferência do usuário. A3. Logging No passo 2 do fluxo básico, a requisição deve ser logada; o sistema armazena a requisição solicitada no arquivo de log. Requisitos especiais Todos as chamadas não devem demorar mais do que 2 segundos.


& Ng (2004), agora isto já pode ser feito, uma vez que adicionando recursos novos, como

o casos de uso slices, podemos separar as propriedades transversais peers, ponto crucial

para esta abordagem.

Na definição do trabalho de Souza (2004) com os casos de uso, é utilizada uma

tabela de composição para identificar o tipo de composição do aspecto em relação ao caso

de uso afetado, bem como uma tabela de resolução de conflitos para o caso em que dois

aspectos diferentes devem ser incluídos no mesmo ponto de junção do caso de uso afetado.

Jacobson & Ng (2004) acreditam que o desenvolvimento de software se resume

a construir modelos. Começamos com o modelo de casos de uso para capturar as

propriedades d o s stakeholders, refinamos este modelo no modelo de análise, o qual

também formula uma visão de alto nível do sistema, preparamos a estratégia de como o

sistema executará na plataforma com o modelo de design, e no modelo de implementação,

temos os códigos atuais e binários.

Isto é previsto por qualquer processo de desenvolvimento existente, porém na

abordagem com casos de uso isto é feito caso de uso por caso de uso através do

refinamento e realização.

Quando este trabalho é terminado (com o caso de uso) temos todos os artefatos

associados com o caso de uso em um simples pacote13, o qual é chamado de módulo de

caso de uso. Este módulo compreende os use-case slices de cada modelo. Os módulos de

casos de uso são desenvolvidos separadamente e depois compostos para formar o sistema

como um todo.

22..22..55 AAbboo rrddaaggeemm TThhee mmee//DDOOCC

A Abordagem Theme é constituída de duas partes: Theme/Doc e Theme/UML.

Elas representam themes em diferentes fases do ciclo de vida (BANIASSAD & CLARKE,

2004b) (CLARKE & BANIASSAD, 2005).

Baniassad & Clarke (2004b) apresentam o theme como sendo um elemento de

design, uma coleção de estruturas e comportamentos que representam uma característica.

13 Tradução literal de package


Na Figura 2.20 é apresentado um conjunto de atividades a serem realizadas por

cada uma das partes, tanto o Theme/Doc quanto o Theme/UML.

FIGURA 2.20 –. O PROCESSO THEME. ADAPTADO DE (CLARKE & BANIASSAD, 2005).

ANÁLISE Requisitos

Themes

Relacionamentos

escolher

visão rede

Base Aspectos

DESIGN

Base Aspectos Aspectos (surgidos do

baixo nível design)

modelos

COMPOSIÇÃO

Design da composição

Especificação da composição

verificar

mostrar

visão

retrabalho

retrabalho

retrabalho

escrever

automático Theme/Doc

Theme/UML


Na Figura 2.20 podemos observar que a representação Theme/Doc é usada para

visualizar e analisar requisitos e Theme/UML é usada na aplicação de projeto. De maneira

geral o processo Theme é dividido em três atividades principais:

a) Análise – onde é realizado a análise dos requisitos para identificação dos

themes. Esta atividade envolve o mapeamento dos requisitos para

propriedades no sistema. Theme/Doc permite a visualização dos

relacionamentos entre os comportamentos. Estes relacionamentos expõem

as propriedades enrolados14 e permite a identificação dos aspectos.

b) Design – O design dos themes é feito utilizando o Theme/UML. No

Theme/Doc identificamos classes e métodos em potencial, depois

preenchemos os detalhes de design e realizamos mudanças que são

necessárias para o benefício do design. Outros aspectos aparecem durante o

detalhamento técnico do design.

c) Composição – Nesta fase especificamos como os modelos Theme/UML

devem ser combinados. Em muitos casos, algumas visões do Theme/Doc

auxiliam na determinação de como os themes se relacionam com outro: se

eles se sobrepõem ou se eles atravessam15 o outro.

Na Figura 2.20 observamos que temos algumas setas com a indicação de

automático, isto é devido a ferramenta citada por Baniassad & Clarke (2004b), porém, não

está disponível para download (THEME, 2006).

Veremos com mais atenção a abordagem Theme/Doc, por se tratar da análise

de requisitos.

Baniassad & Clarke (2004b) definem que aspectos são comportamentos que

estão espalhados pelo sistema e, no documento de requisitos, eles se manifestam como

descrições de comportamentos que estão interconectados e entrelaçados por todo o tempo.

Um ponto interessante nesta abordagem é que não se pode identificar aspectos

em requisitos com termos de ação únicos, ou seja, as ações (ou verbos de ação na

sentença) são considerados como themes. Assim, se todos os requisitos são únicos (se

referem a um único verbo de ação) não possuem aspectos. Neste caso é necessário, muitas

vezes, refazer os requisitos.

14 Tradução literal de tangled 15 Tradução literal de crosscut


Um outro ponto a considerar são os requisitos não funcionais. Nestes casos não

há palavras de ação, porém, eles são transversais por natureza e a solução, nestes casos, é

igualmente refazer os requisitos para incluir tais características.

O modelo Theme/Doc possui dois tipos (observados na Figura 2.20):

a) Base Themes – podem compartilhar estruturas e comportamentos com outros

base themes.

b) Crosscutting Themes (Aspectos) – possui comportamentos que sobrepõe a

funcionalidades dos base themes.

O processo theme/Doc possui as seguintes atividades a serem desenvolvidas:

1) Identificar themes em potencial – a identificação é feita a partir de ações chaves no

documento de requisitos. Na realidade é feita uma análise do documento de requisitos

e identificados entidades chaves e propriedades chaves. Em um próximo passo, é feito

uma iteração sobre o conjunto para decidir se: acrescenta, deleta, divide ou agrupa os

themes. Clarke & Baniassad (2005) argumenta que podemos começar com a escolha

de nomes de características, serviços, ou casos de uso do sistema para chegar no ponto

inicial de themes. Baniassad & Clarke (2004b) indica a escolha dos verbos de ação

para o ponto inicial dos themes e a partir daí ir refinando para encontrar os themes

exatos para o sistema. Um ponto a considerar é que nem todas as características serão

themes, porém esta tarefa de escolha das entidades e palavras de ação ainda é manual

na ferramenta (THEME, 2006) e depende da experiência do engenheiro de requisitos.

É importante observar que palavras sinônimas que se referem a mesma ação devem ser

agrupadas sobre uma única palavra de ação. Com esta atividade realizada a ferramenta

gera o gráfico de Visão de Ações – Figura 2.21. Onde a elipse é um theme e um

retângulo se refere ao requisito.


FIGURA 2.21 –. EXEMPLO ABSTRATO DO GRÁFICO DE VISÃO DE AÇÕES16. ADAPTADO DE (CLARKE &

BANIASSAD, 2005).

2) Refinar o conjunto de themes - Se um requisito (Requisito 1 da Figura 2.21) é ligado a

mais de uma palavra de ação, está caracterizado um comportamento enrolado17 ou

complicado. Este relacionamento deve ser analisado para verificar se é uma má

especificação de requisitos ou se existe um comportamento crosscutting. No caso de

muitas ligações entre os requisitos a palavras de ação, onde a verificação foi feita e foi

decidido que é do jeito que está especificado, a ação predominante para o requisito

deve ser definida (e assim selecionada como base), e a segunda ação deve ser ligada a

primeira, indicando que a segunda ação /comportamento atravessa o comportamento

base. Após todos os requisitos compartilhados serem ligados ao seu comportamento

secundário o gráfico de Visão de Ações Ligadas é obtido, conforme a Figura 2.22.

Nesta figura a linha pontilhada indica que não houve decisão a ser tomada com

respeito ao requisito 3, a linha cinza indica que o primeiro theme crosscutt o segundo

theme. Podemos observar ainda que o primeiro theme domina o requisito 1. Assim,

neste gráfico a linha cinza indica o relacionamento de crosscutting.

16 BANIASSAD&CLARKE ( 2004b). chamam este gráfico de Action Views e em CLARKE & BANIASSAD ( 2005) este mesmo gráfico é chamado de Relationship view, porém são idênticos nos conceitos. 17 Tradução literal de tangling

Primeiro

Theme

Segundo

Theme

Terceiro

Theme

Requisito 1: se refere ao primeiro e segundo

theme

Requisito 2: se refere

ao terceiro theme


FIGURA 2.22 –. EXEMPLO ABSTRATO DO GRÁFICO DE AÇÕES LIGADAS18. ADAPTADO DE (CLARKE & BANIASSAD,

2005).

3) Preparar para design – O gráfico theme view é usado para planejar o design e a

modelagem dos themes identificados no passo anterior. Este gráfico difere do gráfico de

visão de ações no sentido de que não apenas mostrar os requisitos e as ações, mas também

mostrar os elementos do sistema necessários a serem considerados para cada theme design

no Theme/UML. Para construir esta visão o desenvolvedor/engenheiro de requisitos deve

fornecer um conjunto adicional de informações, as entidades chave. A figura 2.23 mostra

um exemplo deste gráfico. Usamos o theme view para planejar as classes e métodos no

Theme/UML. Ao modelarmos usamos as práticas de design de orientação a objetos para

auxiliar na determinação de quais classes e métodos são descritos. Na maior parte dos

casos os métodos são as ações e as classes são as entidades, porém podemos acrescentar

outras entidades e métodos como decisões de design.

Assim, torna-se claro que apesar de endereçar quase todos os requisitos ainda

não é suficiente se este endereçamento irá suprir todas as necessidades (de classes e

entidades), uma vez que pode ser acrescido de elementos não identificados inicialmente.

18 BANIASSAD&CLARKE (2004b). chama este gráfico de Clipped Views e em CLARKE & BANIASSAD (2005) chama este gráfico de Crosscutting view, porém os conceitos são os mesmos.

Primeiro

Theme

Segundo

Theme

Terceiro

Theme

Requisito 1: se refere ao primeiro e segundo theme

Requisito 3: se refere ao terceiro theme


FIGURA 2.23 –. EXEMPLO ABSTRATO DO GRÁFICO DE THEME VIEW. ADAPTADO DE (CLARKE &

BANIASSAD, 2005).

22..33 CCoo mmppaa rraaççããoo eennttrree AAbboo rrddaaggeennss AApprree sseennttaa ddaass

Todas as abordagens possuem um ponto em comum quando afirmam que com

a identificação de propriedades transversais nas fases iniciais do processo de

desenvolvimento pode-se obter benefícios da sua utilização nos artefatos de requisitos,

análise e projeto, e não apenas na implementação, como era feito logo no início da

orientação a aspectos.

Partindo desta premissa e baseado nas características de qualidade elaboradas

pela ISO/IEC 9126, definimos algumas características a serem consideradas para a

comparação entre as abordagens, que definimos de acordo com a Tabela 2.9 e 2.10

A Tabela 2.9 apresenta as características gerais e seus conceitos, de acordo

com a norma ISO/IEC 9126 e adaptadas para o nosso propósito, e a Tabela 2.10 apresenta

as sub-características que servirão de base à comparação efetuada, apresentada na Tabela

2.12.

Primeiro

Theme

Segundo

Theme

Terceiro

Theme


Requisito 3: se refere ao primeiro theme e ao terceiro theme


Primeiro

elemento

Segundo

elemento


Vale observar que as sub-características listadas na Tabela 2.10 correspondem

a uma adaptação das sub-características originais, apresentadas nas normas ISO/IEC 9126.

As sub-características em fundo amarelo foram incluídas para realizar a comparação e não

existia originalmente. As outras foram adaptadas em seus conceitos para realizar tal

comparação

TABELA 2.9 – ADAPTAÇÃO DOS CONCEITOS DAS CARACTERÍSTICAS DE QUALIDADE ISO/IEC 9126

Características de Qualidade

Funcionalidade Evidencia que o conjunto de funções atende às necessidades

explícitas e implícitas para a finalidade a que se destina a

abordagem.

Confiabilidade Evidencia que o desempenho se mantém ao longo do ciclo ou

fase a que se destina e em condições estabelecidas.

Usabilidade Evidencia a facilidade para a utilização da abordagem.

Eficiência Evidencia que os recursos e os tempos envolvidos para a

aplicação da abordagem são compatíveis com o nível de

desempenho requerido para a aplicação da abordagem.

Manutenibilidade Evidencia que há facilidades para correções, atualizações e

alterações durante a sua aplicação.

Portabilidade Evidencia que é possível utilizar a abordagem em diversas

plataformas (utilizando sua ferramenta Case) com pequeno

esforço de adaptação.


TABELA 2.10 – SUB-CARACTERÍSTICAS PARA COMPARAÇÃO DAS ABORDAGENS

Caracteristica Sub-caracteristica Conceito

Abrangência Indica qual a fase do processo de desenvolvimento é considerada na abordagem

Adequação A abordagem deve ter um conjunto de funções/passos apropriados para a separação e composição de propriedade

Acurácia Geração de resultados satisfatórios. (indicar ponto fraco)

Interoperabilidade Capacidade de interagir com outros produtos

Funcionalidade

Conformidade Estar de acordo com normas, convenções e regulamentações.

Origem Ano do primeiro trabalho publicado da proposta Confiabilidade

Maturidade Grau de maturidade da proposta

Artefatos Principal artefato utilizado para a elucidação dos aspectos e propriedades

Apoio Case Indica se a abordagem possui ferramenta Case de Apoio

Inteligibilidade Facilidade oferecida ao usuário em entender os conceitos utilizados

Usabilidade

Apreensibilidade Facilidade de aprendizado

Resolução de Conflitos Indica se a abordagem possui mecanismos ( e seu nível) bem definidos para a resolução de conflitos

Tratamento de Requisitos

Organizacionais

Indica se a abordagem possui estratégia de tratamento para requisitos organizacionais.

Requisitos funcionais – aspectos

Indica se a abordagem considera que requisitos funcionais possam ser aspectos

Requisitos não funcionais – aspectos

Indica se a abordagem considera que requisitos não funcionais possam ser aspectos;

Eficiência

Comportamento em relação aos recursos

Quantidade de recursos (artefatos) utilizados para a execução das tarefas

Rastreabilidade Indica se a abordagem oferece um método para realizar o rastreamento de aspectos durante o ciclo de vida de desenvolvimento

Analisabilidade Facilidade de diagnosticar deficiências e causas de falhas

Modificabilidade Facilidade de modificação e remoção de defeitos

Manutenibilidade

Testabilidade Facilidade da abordagem ser testada e validada

Adaptabilidade Capacidade de ser adaptada a ambientes diferentes

Capacidade para ser instalada

Facilidade para executar a instalação em ambientes específicos (ao possuir ferramenta que a implemente)

Portabilidade

Capacidade para substituir

Facilidade em substituir outra abordagem utilizada pelos desenvolvedores


Para os critérios utilizados para a comparação efetuada entre as abordagens

adotou-se três níveis de avaliação: fraca, regular e boa. A especificação de cada uma

encontra-se na Tabela 2.11. Este critério foi utilizado na comparação efetuada na tabela

2.12.

TABELA 2.11 – CRITÉRIOS DE PADRÕES UTILIZADOS NA COMPARAÇÃO

Critérios Característica Boa Regular Fraca

Abrangência Abrange a todas as fases do desenvolvimento de software

Abrange mais que uma fase do desenvolvimento de software.

Abrange apenas uma fase do desenvolvimento de software.

Adequação Conjunto de artefatos e fases bem definidas

Um ou mais artefatos com pouca ou nenhuma definição ou uma ou mais fases com pouca ou nenhuma definição

Um ou mais artefatos com pouca ou nenhuma definição e uma ou mais fases com pouca ou nenhuma definição

Acurácia Gera todos os artefatos de forma satisfatória e com objetividade

Deixa de gerar um artefato de forma satisfatória ou com pouca objetividade

Deixa de gerar mais de um artefato de forma satisfatória ou com pouca objetividade

Interoperabilidade Feita através de uma especificação para a exportação em formato padrão (XML, MOF, etc.)

Possui exportação para alguns formatos, porém dentro da própria família do fabricante.

Não possui

Conformidade Segue padrões conhecidos (UML, etc)

Segue padrão da própria família do fabricante.

Não possui padrão

Origem* Não possui critério. Apenas indica o ano da primeira publicação da abordagem.

Maturidade Possui várias publicações (mais de 3) e/ou livro da abordagem

Possui publicações (até três) , porém não há livro sobre o assunto.

Possui até duas publicações.

Artefatos

Possui mais de três artefatos (gráficos, tabelas, etc) para apoiar a abordagem

Possui até três artefatos. Possui um artefato principal.

Apoio Case

Possui ferramenta case disponível para apoiar o desenvolvimento

Possui ferramenta, mas não se encontra disponível para download

Não possui ferramenta case.

Inteligibilidade Artefatos simples e bem definidos

Possui artefatos simples e alguns complexos

Artefatos complexos e difíceis de entender

Apreensabilidade

Objetiva e fácil de entender os conceitos

Conceitos mais complexos, porém não apresenta dificuldade alta.

Conceitos complexos e com grau de dificuldade médio para alto

Resolução de Conflitos Apresenta mecanismos simples e bem definidos

Apresenta mecanismos complexos para resolução de conflitos

Não apresenta mecanismos

Tratamento de Requisitos organizacionais

Possui tratamento de forma diferenciada

Possui tratamento de forma unificada com RNF

Não possui

Requisitos funcionais – aspectos

Considera e possui tratamento específico

Considera, mas não pos-sui tratamento diferenci-ado ou não explica como

Não considera

Continua na próxima página


Continuação da Tabela 2.11 Critérios Característica

Boa Regular Fraca


Considera e possui tratamento específico

Considera, mas não pos-sui tratamento diferenci-ado ou não explica como

Não considera


Não possui quantidade definida (ou possui sem o rigor da obrigatoriedade), porem todos são bem objetivos e simples

Possui quantidade definida e todos são necessários

Possui quantidade bem definida, porém alguns não são bem objetivos

Rastreabilidade

Possui mecanismos para rastrear aspectos de forma simples e direta

Possui mecanismos, porém sem rastreabilidade durante a fase inicial

Não possui

Analisabilidade Facilmente detectável, mesmo que de forma manual

detectável, porem com o uso de ferramenta própria

Não possui ou possui de forma complexa e pouco usual

Modificabilidade Facilmente modificável (com ajuda de ferramenta case)

Modificação complexa Não possui

Testabilidade Facilmente testável Dificuldade maior

(depende de aprovação) Não possui

Adaptabilidade Independente de ambiente

Com adaptações Não possui

Capacidade para ser instalada

Linguagem independente de plataforma

Diferentes versões para plataformas distintas

Não disponível

Capacidade para substituição

Sem problema, apenas incorporar novos conceitos

Alguns conceitos complexos com a mudança porém utilizando a mesma base da abordagem

Mudanças complexas e totais no desenvolvimento

A Tabela 2.12 apresenta a comparação entre as abordagens estudadas neste

capítulo. Alguns estudos comparativos entre as abordagens utilizam outros critérios de

avaliação, como o tipo de regra de composição utilizada, por exemplo. Porém utilizamos

os critérios de qualidade das normas ISO/IEC 9126 por ter maior abrangência, de forma a

evidenciar as diferenças e dificuldades entre cada abordagem.


TABELA 2.12 – COMPARAÇÃO DAS ABORDAGENS AORE

Abordagem FATORES

Viewpoint Goals Use Case Theme /Doc Abrangência fraca fraca boa boa Adequação fraca fraca regular regular Acurácia fraca.

identificação dos propriedadess

fraca. refinação de objetivos

regular regular

Interoperabilidade regular. fraca fraca fraca

Fu

nci

on

alid

ade

Conformidade regular Boa (i* com adaptações)

Boa (UML com adaptações)

regular

Origem 2002 2004 2003 2004

Co

nfi

abi-

lidad

e

Maturidade regular regular boa boa

Artefatos Boa (XML) Boa (V-GRAPH

refinados) Boa (Casos de Uso)

Boa (Gráfico Theme-Doc )

Apoio Case Regular (ARCADE)

Boa(OPENOME) fraca Fraca (Theme/DOC Tool)

Inteligibilidade regular Boa regular regular

Usa

bil

idad

e

Apreensabilidade regular regular regular regular

Resolução de Conflitos boa boa regular regular

Tratamento de Requisitos organizacionais

fraca fraca fraca fraca

Requisitos funcionais – aspectos fraca fraca regular Boa


Boa Boa Boa Boa Efi

ciên

cia


regular Boa Boa regular

Rastreabilidade boa boa boa boa

Analisabilidade boa boa Regular

(sem ferramenta)

Regular (não disponível)

Modificabilidade Boa (com restrições)

Boa regular Boa (com restrições)

Man

ute

nib

ilid

ade

Testabilidade regular boa fraca regular

Adaptabilidade boa Regular regular fraca

Capacidade para ser instalada Boa (com restrições)

Boa fraca fraca

Port

abil

idad

e

Capacidade para substituição

Boa (se anterior for Viewpoint, senão será regular)

Boa (se anterior for Goals – senão será regular)

regular fraca


As tabelas 2.13, 2.14, 2.15 e 2.16 apresentam um resumo das características de

qualidade, apresentando os principais problemas encontrados. Este resumo foi baseado nas

respostas apresentadas e proporciona uma visão geral da Tabela 2.12.

TABELA 2.13 – RESUMO DA COMPARAÇÃO – ABORDAGEM VIEWPOINT

Abordagem Viewpoint

Funcionalidade:

Fraca

Sua principal dificuldade está na identificação das propriedades, onde esta atividade não está definida objetivamente. Deixando a cargo da “experiência” do engenheiro de requisitos.

Confiabilidade:

Fraca

Apesar de ter sua origem na orientação a objetos, esta abordagem ainda não possui a maturidade necessária para ser considerada regular. Esta classificação deve-se ao fato de estar particularmente focada em uma universidade e não ter vasto material de pesquisa disponível.

Usabilidade

regular

Apesar de possuir fases bem objetivas e definidas com seus artefatos, a primeira fase não é bem definida (sendo a mais importante). Seus artefatos possuem facilidade de aprendizado e são bem simples no seu conteúdo, o que garantiu uma classificação regular.

Eficiência

regular

Apesar de não tratar requisitos organizacionais e não considerar requisitos funcionais como aspectos, esta abordagem possui um bom método para tratamento de conflitos e tratamento para requisitos não funcionais de forma bem específica, o que garantiu uma classificação regular

Manutenibilidade

boa

Esta classificação se deve ao fato de que esta abordagem possui um bom nível de rastreabilidade, mesmo que manual, porém com um pouco mais de trabalho e uma boa manutenção (se estiver com a ferramenta).

Portabilidade

Boa

A substituição para esta abordagem será mais simples se a abordagem anterior for a OO para Viewpoint, senão será um pouco mais complicado. Possui ferramenta para auxílio feita em Java, porem sem possibilidade de download. O que dificulta um pouco a avaliação como um todo.


TABELA 3.14 – RESUMO DA COMPARAÇÃO – ABORDAGEM GOALS

Abordagem GOALS

Funcionalidade:

Fraca

Sua principal dificuldade está no refinamento sucessivo dos objetivos e suas operacionalizações, uma vez que esta atividade não está definida claramente, deixando a cargo da “experiência” do engenheiro de requisitos.

Confiabilidade:

Regular

Apesar de ter sua origem na orientação a objetos com a modelagem i*, esta abordagem ainda não possui a maturidade necessária para ser considerada boa. Esta classificação deve-se ao fato de estar sendo utilizada por algumas faculdades (inclusive em cursos de especialização – UNIOESTE no Paraná) e ter vasto material de pesquisa disponível.

Usabilidade

Boa

O método em si é bem simples, pois baseia-se no refinamento sucessivo de objetivos, o que garante a classificação atual.

Eficiência

regular

Conceitualmente a modelagem i* pode tratar requisitos organizacionais (em trabalhos adicionais como em SANTANDER (2002)), porém não especifica este assunto, tratando apenas das operacionalizações dos requisitos não funcionais.

Manutenibilidade

Boa

Possui uma boa rastreabilidade (através do refinamento sucessivo dos objetivos) e uma boa analisabilidade (através das tarefas que satisfazem os objetivos).

Portabilidade

Boa

A substituição da visão OO (i*) para a visão de aspectos é bem simples, pois os conceitos são praticamente os mesmos, caso contrario fica mais complexo o processo de substituição, porém os conceitos são simples. A ferramenta possui várias versões diferentes e está disponível para download.


TABELA 2.15 – RESUMO DA COMPARAÇÃO – ABORDAGEM USE CASE

Abordagem USE CASE

Funcionalidade:

Regular

Sua principal dificuldade está na definição dos casos de uso como um todo, iniciar o processo de desenvolvimento com a definição dos casos de uso não é uma tarefa trivial. Suas fases são completas e complexas, o que garante uma classificação regular.

Confiabilidade:

Boa

Uma das únicas abordagens conhecidas que possuem definição para todas as fases do processo de desenvolvimento. O que garante uma classificação boa.

Usabilidade

Regular

Mesmo para quem utiliza os casos de uso, são muitos conceitos novos e complexos, o que garante a classificação atual.

Eficiência

Regular

Conceitualmente os casos de uso tratam apenas de funcionalidades do sistema. Com esta abordagem eles passam a tratar dos requisitos não funcionais, sem abordar os requisitos organizacionais..

Manutenibilidade

Regular

Não possuindo uma ferramenta case para auxiliar o processo, fica complexo e demanda tempo a tarefa de manutenção, analisabilidade e rastreamento.

Portabilidade

Regular

A substituição da visão OO para a de aspectos não é simples, pois abrange vários conceitos novos e complexos, o que garantiu a classificação regular.


TABELA 2.16 – RESUMO DA COMPARAÇÃO – ABORDAGEM THEME/DOC

Abordagem THEME/DOC

Funcionalidade:

Regular Sua principal dificuldade está na definição dos themes, pois é uma tarefa manual, porém o processo de construção dos requisitos na abordagem é bem simples, o que garante a classificação atual.

Confiabilidade:

Boa Uma das únicas abordagens conhecidas que possuem definição para todas as fases do processo de desenvolvimento. O que garante uma classificação boa.

Usabilidade

Regular Mesmo sendo uma abordagem completamente diferente e recente, garante esta classificação por ser bem simples. É fácil de ser compreendida e de ser usada, apesar da ferramenta case não estar disponível. É a que mais se aproxima da especificação do LEL (mesmo que nem cite o mesmo)

Eficiência

Regular Consegue tratar requisitos funcionais e não funcionais com simplicidade, apesar de ter regras rígidas para a composição dos mesmos. A identificação dos aspectos é bem simples e possui tratamento para a resolução de conflitos.

Manutenibilidade

Regular Não possuindo uma ferramenta case disponível para download para auxiliar o processo fica complicado a tarefa de manutenção, analisabilidade e rastreamento.

Portabilidade

Fraca A substituição para esta abordagem não é simples, uma vez que é completamente diferente das outras e de um padrão já existente em OO. Não há informação sobre a ferramenta e sua implementação, o que dificulta o processo de análise.

TABELA 2.17 – RESUMO GERAL DA COMPARAÇÃO

Abordagem Fatores

Viewpoint Goals Use Case Theme /Doc

Funcionalidade Fraca Fraca. Regular Regular.

Confiabilidade Fraca Regula Boa Boa

Usabilidade regular Boa Regular Regular

Eficiência regular regular Regular Regular

Manutenibilidade boa Boa Regular Regular

Portabilidade Boa Boa. Regular Fraca


A Tabela 2.17 demonstra que apesar dos esforços oriundos dos estudos das

abordagens, muitos atributos são frágeis em relação ao que se propõem. Assim, um estudo

mais aprofundado, englobando estudos de caso em cada abordagem é imprescindível para

avaliar melhor o impacto de cada uma das abordagens apresentadas, ficando de sugestão

como trabalho futuro a ser apresentado.

22..44 RReessuummoo ddoo CCaa ppííttuulloo

Neste capítulo foram apresentados os principais conceitos do desenvolvimento

orientado a aspectos e as principais abordagens apresentadas na Engenharia de Requisitos.

Ao final apresentamos uma comparação entre as abordagens com o intuito de evidenciar

as diferenças (vantagens e desvantagens) entre cada uma.

Esta comparação é importante a partir do q u e será a base para o

desenvolvimento da nova abordagem.

Neste capítulo identificamos que uma das principais dificuldades apresentadas

pelas abordagens está em como identificar propriedades, propriedades transversais e, por

conseqüência, aspectos. De maneira geral, as abordagens definem estes conceitos, porém

não nos dizem como fazer e, sabemos que este é o ponto principal de dificuldade

apresentada na maioria das abordagens e metodologias existentes, o de como fazer.

Deste modo, fica evidente o porquê de tantas pesquisas e abordagens para

tentar minimizar os problemas encontrados.

No próximo capítulo veremos alguns conceitos gerais da MDSODI, do

ambiente DISEN e da ferramenta Requisite.

3.A Metodologia MDSODI e o Ambiente DiSEN 65

CAPÍTULO

33

A METODOGIA MDSODI E O AMBIENTE DISEN

Eu não consigo entender por que as pessoas têm medo das novas idéias, eu tenho medo das velhas.

John Cage

DDeessddee mmeeaaddooss ddaa ddééccaaddaa ddee 7700 ccoomm aa AAnnáálliissee EEss ttrruuttuurraaddaa,, ooss

ddeesseennvvoollvveeddoorreess tteemm ssee ddeeppaarraaddoo ccoomm ss iiss tteemmaass ccaaddaa vveezz mmaaiiss

ccoommpplleexxooss ee dd iiffíícceeiiss ddee mmeennssuurraarr ee eenntteennddeerr ddee uummaa mmaanneeiirraa mmaaiiss

ss iimmpp lleess ee ccoommpplleettaa,, ddaaíí tteemm ssuurrggiiddoo ttaannttaass mmeettooddoollooggiiaass ee aabboorrddaaggeennss

ddiiffeerreenntteess ppaarraa eessppeecc iiffiiccaaççããoo ddee ss iiss tteemmaass .. PPrreessssmmaann ((22000055)),, mmuuiittoo

ssaabbiiaammeennttee,, jjáá dd iizz iiaa qquuee nnóóss nnooss cceerrccaammooss ddee vváárr iiaass mmeettooddoollooggiiaass ee

eessppeecc iiff iiccaaççõõeess aappeennaass ppaarraa ggaarraanntt iirr qquuee eess ttaammooss ccoommpprreeeennddeennddoo oo qquuee

eess ttaammooss ffaazzeennddoo..

AA vveerrddaaddee éé qquuee ccoomm oo aavvaannççoo ddaa tteeccnnoollooggiiaa,, aa tteennddêênncciiaa éé qquuee

tteennhhaammooss ss iiss tteemmaass ccaaddaa vveezz mmaaiiss ccoommpplleexxooss .. PPoorrttaannttoo,, oo ssuurrggiimmeennttoo

ddee nnoovvooss mmééttooddooss ee ttééccnniiccaass ddee ddeesseennvvoollvviimmeennttoo ssããoo pplleennaammeennttee

ccoommpprreeeennss íívveeiiss ,, ttaannttoo nnoo qquuee dd iizz rreessppeeiittoo àà nnoossssaa ccoommpprreeeennssããoo qquuaannttoo

nnoo qquuee ddiizz rreessppeeiittoo àà tteeccnnoollooggiiaa ee sseeuu aavvaannççoo..


NNeess ttee ppoonnttoo eennttrraa aa MMeettooddoollooggiiaa ddee DDeesseennvvoollvviimmeennttoo ddee SSooffttwwaarree oouu

SSiiss tteemmaass DDiiss ttrr iibbuuííddooss –– MMDDSSOODDII11 ((GGRRAAVVEENNAA,, 22000000)),, qquuee lleevvaa eemm

ccoonnss iiddeerraaççããoo aallgguummaass ccaarraacc tteerríí ss ttiiccaass iiddeenntt iiff iiccaaddaass eemm ttaa iiss ss iiss tteemmaass ,,

ccoommoo:: ppaarraa llee lliissmmoo//ccoonnccoorrrrêênncciiaa,, ccoommuunniiccaaççããoo,, ss iinnccrroonniizzaaççããoo ee

ddiiss ttrriibbuuiiççããoo,, jjáá nnaass ffaasseess iinniicc iiaa iiss ddoo pprroojjeettoo..

EEss ttee ccaappíí ttuulloo tteemm ppoorr oobbjjeett iivvoo aapprreesseennttaarr ee ddeessccrreevveerr aa MMDDSSOODDII,,

aapprreesseennttaarr oo AAmmbbiieennttee ddee DDeesseennvvoollvviimmeennttoo ddee SSooffttwwaarree DDiiss ttrr iibbuuííddoo ––

DDiiSSEENN ((PPAASSCCUUTTTTII,,22000022)) ee aa ffeerrrraammeennttaa RREEQQUUIISSIITTEE ((BBAATTIISSTTAA,,

22000033)) eemm sseeuu eess ttaaddoo aattuuaall..

33..11 AA MMeettoo ddoolloogg iiaa MMDDSSOODDII

A MDSODI é uma metodologia para desenvolvimento de software distribuído e

foi proposta por Gravena (2000). Esta metodologia considera aspectos de

concorrência/paralelismo, comunicação, sincronização e distribuição no seu desenvolvimento

em todas as fases do desenvolvimento de software. Estes aspectos são representados através

da extensão UML (GRAVENA, 2000) (HUZITA, 1999).

O modelo do ciclo de vida da MDSODI e suas fases podem ser visto na Figura 3.1.

FIGURA 3.1 – CICLO DE VIDA DO MDSODI. FONTE: (GRAVENA, 2000)

1 EEss ttaa mmeettoo dd oo lloo gg iiaa ffoo ii dd eess eenn vv oo llvv iidd aa aatt rraavv ééss dd ee uu mm pp rroo jjeettoo dd ee pp eess qq uu iiss aa eemm 1199 99 99 (( HH UUZZIITTAA ,, 11 99 9999 )) nn oo LLaabb oo rraattóó rriioo dd ee EEnn gg eenn hh aarriiaa dd ee SSoo fftt wwaarree (( LLEESS)) dd oo DDeepp aarrttaa mmeenn ttoo dd ee IInn ffoo rr mmáátt iiccaa ((DD II NN)) dd aa UUnn iivv eerrss iidd aadd ee EEss ttaadd uu aall dd ee MMaarriinn gg áá

((UU EEMM ))..

GERENCIAMENTO

Inc #1 Inc #1

Inc #1 Inc #1

...

Requisitos Análise Projeto Implementação Teste


Cada incremento é composto das fases de requisitos, análise, projeto,

implementação e teste, conforme observado na Figura 3.1. Cada fase possui os seguintes

objetivos:

1. Fase de Requisitos – Identificar as funcionalidades necessárias para o desenvolvimento

do sistema de uma forma adequada e eficiente a partir das necessidades do usuário.

Nesta fase, devem-se entender os requisitos funcionais e não funcionais e elaborar o

diagrama de casos de uso considerando os aspectos de paralelismo/concorrência e

distribuição. Os artefatos produzidos são: modelo de negócio, diagrama de use case e

descrição de requisitos.

2. Fase Análise – Com base nos requisitos identificados na fase anterior, bem como os

diagramas de casos de uso, definem-se as classes e objetos do sistema, identificando

aspectos de concorrência/paralelismo, distribuição e comunicação entre as classes.

Devem-se também identificar os aspectos de concorrência/paralelismo e a distribuição

entre pacotes através de descrição textual, quando necessário, e elaborar o diagrama de

pacotes considerando estes aspectos. Nesta fase são produzidos os artefatos: diagramas

de classe, diagrama de colaboração, diagrama de estado, diagrama de pacotes e

descrição arquitetural do modelo de análise.

3. Fase de Projeto – Nesta fase é elaborado o diagrama de classes de projeto, definição de

aspectos da arquitetura do sistema, identificando a alocação dos pacotes nas camadas, e

detalhamento de algoritmos, todos considerando os aspectos de paralelismo e

distribuição. Nesta fase são produzidos os artefatos: diagrama de seqüência

(paralelismo, distribuição e comunicação), lista com os requisitos de implementação

(linguagem e ambiente de programação escolhidos), localização física e questões de

concorrência (entre métodos), diagrama de subsistema (considerando sincronização,

paralelismo, distribuição e comunicação), divisão do sistema em camadas, aspectos

arquiteturais do projeto, averiguação de componentes disponíveis para reutilização e

detalhamento dos métodos.

4. Fase de Implementação – esta fase tem como objetivo a construção e implementação do

sistema, tendo como base aspectos identificados nas fases anteriores. Nesta fase devem

ser definidas as interfaces entre os subsistemas identificados na fase de projeto e

detalhar e implementar os métodos das classes. Os mecanismos de sincronização e os

que tratam do balanceamento de carga entre os nós do processamento, considerando os

requisitos de distribuição, paralelismo, sincronização e comunicação devem ser tratados.


5. Fase de teste – constitui-se em um trabalho a ser desenvolvido (GRAVENA, 2000).

A MDSODI propõe também uma definição de notação para a especificação de

seus elementos nos artefatos (Casos de uso, atores, classes e objetos, e relacionamentos). A

tabela 3.1 ilustra esta especificação adotada.

TABELA 3.1 – ESPECIFICAÇÃO DOS ELEMENTOS UTILIZADOS NA MDSODI. FONTE: (GRAVENA, 2000)

Tipos de Casos de Uso

Casos de Uso Notação

Casos de Uso Seqüenciais: agrupam um conjunto de funcionalidades que devem ser executadas seqüencialmente.

Casos de Uso Paralelos: agrupam um conjunto de funcionalidades que devem ser executadas em paralelo. Casos de Uso Distribuídos: podem estar em diferentes locais do sistema.

Casos de Uso Paralelos e Distribuídos: podem estar em diferentes locais do sistema e devem ser executados em paralelo.

Tipos de Atores

Atores Notação

Atores Exclusivos: atores envolvidos com casos de uso seqüenciais.

Atores Paralelos: atores envolvidos com casos de uso paralelos.

Atores Distribuídos: atores que se encontram localizados em diferentes nós no sistema.

Atores Paralelos e Distribuídos: atores que são, ao mesmo tempo, paralelos e distribuídos.

Tipos de Classes/Objetos

Classes/Objetos Notação

Classes e Objetos Exclusivos: Todos os seus métodos são executados sequencialmente.

Classes e Objetos Parcialmente Paralelos: alguns métodos são executados sequencialmente enquanto outros concorrentemente.


Classes e Objetos Totalmente Paralelos: todos os métodos são executados concorrentemente.

Classes e Objetos Distribuídos: os métodos podem ser executados em diferentes nós do sistema.

Tipos de Relacionamentos – poderão ser utilizados também os relacionamentos convencionais

da orientação a objetos como, a agregação e generalização. Relacionamento Notação

Relacionamento entre casos de uso exclusivos: casos de uso que são executados sequencialmente (requisitos).

Relacionamento entre casos de uso paralelos: casos de uso que são executados concorrentemente com outros casos de uso (requisitos).

Relacionamento entre pacotes exclusivos: pacotes que são executados sequencialmente (análise).

Relacionamento entre pacotes parcialmente paralelos: são pacotes que possuem classes executadas de forma concorrente com outras classes de outro pacote (análise).

Relacionamento entre pacotes totalmente paralelos: são pacotes que todas as classes são executadas de forma concorrente com outras classes de outro pacote (análise).

Relacionamento entre pacotes distribuídos: são pacotes localizados em diferentes nós do sistema (análise).

R e l a c i o n a m e n t o e n t r e módulos/subsistemas exclusivos: subsistemas/módulos que são executados sequencialmente (projeto).

Relacionamento entre módulos/subsistemas parcialmente paralelos: subsistemas/módulos que tem algumas classes executadas de forma concorrente com outras classes de outro subsistema (projeto).

Relacionamento entre módulos/subsistemas totalmente paralelos: subsistemas/módulos que todas as classes são executadas de forma concorrente com outras classes de outro subsistema (análise).

Relacionamento entre módulos/subsistemas distribuídos: subsistemas/módulos localizados em diferentes nós dentro do sistema (projeto).

Relacionamento entre objetos exclusivos: objetos que tem seus métodos executados sequencialmente.

Relacionamento entre objetos parcialmente paralelos: objetos que tem alguns métodos executados concorrentemente. Relacionamento entre objetos totalmente paralelos: objetos que tem todos os seus métodos executados concorrentemente. Relacionamento entre objetos distribuídos: objetos que se encontram localizados em diferentes nós do sistema.


33..22 OO AAmmbbiieennttee DDiiSSEENN

Pascutti (2002) define o DiSEN como sendo um ambiente distribuído de

desenvolvimento de software, no qual a MDSODI está inserida. O DiSEN tem como um de

seus objetivos o de permitir que vários desenvolvedores, atuando em locais distintos, possam

trabalhar de forma cooperativa no desenvolvimento de software, permitindo a interação de

profissionais geograficamente dispersos, resultando em uma melhor qualidade dos produtos

desenvolvidos.

A arquitetura do DiSEN é baseada em camadas (ver figura 3.2) onde possui uma

camada dinâmica que é a responsável pelo gerenciamento da configuração e reconfiguração

do ambiente em tempo de execução; uma camada de aplicação que tem como um dos

elementos constituintes o suporte à MDSODI, e a camada da infra-estrutura, que provê

suporte às tarefas de persistência, nomeação e concorrência e, além disso, incorpora o canal

de comunicação.

FIGURA 3.2 – O AMBIENTE DISEN E SUA ESTRUTURA EM CAMADAS. FONTE (PASCUTTI, 2002).

Abaixo do canal de comunicação, existe uma camada de software básico do

sistema, que irá conter interfaces para hardware específico, sistema operacional, memória

compartilhada e comunicação.

O canal de comunicação é um elemento fundamental desta arquitetura, pois toda a

comunicação entre os elementos constituintes da camada de aplicação e da camada de infra-

estrutura será realizada através deste canal. É constituído pelo middleware e pelo middle-

agent, sendo que, quando a comunicação envolver somente objetos, esta será feita pelo

Supervisor de Configuração Dinâmica

Repositório Gerenciador de Objetos

Gerenciador de Workspace

Gerenciador de Agentes

Canal de Comunicação

Suporte à Tarefa de

Persistência


Nomeação


Concorrência

Camada dinâmica

Camada de Aplicação

Camada de Infra-Estrutura

middleware Middle-agent


middleware e, quando os agentes estiverem envolvidos, devido às suas propriedades, a

comunicação deverá ser gerenciada pelo middle-agent.

O Supervisor de Configuração Dinâmica é o responsável pelo controle e

gerenciamento da configuração do ambiente, bem como dos serviços que podem ser

acrescentados ao ambiente em tempo de execução.

O Gerenciador de Objetos é responsável pelo controle e gerenciamento do ciclo

de vida dos artefatos, que pode ser um diagrama, modelo, manual, código fonte, entre outros.

O Gerenciador de objetos é constituído por gerenciador de acesso, de atividades, de recursos,

de artefatos, de projetos, de processos e de versões e configurações.

Por ser de interesse para o REQUISITE e, por conseguinte, para o nosso trabalho,

descreveremos com mais detalhes o gerenciador de recursos. Este é o responsável pelo

controle e gerenciamento de recursos para a execução de uma atividade. Os recursos

necessários para a realização das atividades podem ser materiais (computador, impressora,

sala de reunião) ou ferramentas (programas de computador destinados ao suporte ou

automação de parte do trabalho relacionado a uma atividade). Para o DiSEN, a ferramenta

REQUISITE é considerada como um de seus recursos.

O Gerenciador de Workspace é responsável pelo controle e gerenciamento da

edição cooperativa de documentos e itens de software e também por administrar um conjunto

de workspaces. P ascutti (2002) define ainda que o gerenciador de workspace prove

funcionalidades para criar um ou mais workspaces (isto seria feito através do canal de

comunicação e do suporte à tarefa de persistência, conforme a figura 3.3). No caso mais

simples consistiria na cópia de um arquivo, porém poderia ser copiada toda uma configuração

do repositório para o workspace, possibilitando o desenvolvedor ter todos os módulos e

documentos necessários para o funcionamento do sistema a sua disposição localmente.

Uma das principais vantagens é a de que o desenvolvedor está isolado das

alterações das outras pessoas para o repositório, ou seja, possui um controle sobre seu mundo,

sabendo o que foi alterado e por que foi alterado.

Quando o desenvolvedor de software termina de efetuar suas modificações, ele

precisa adicionar os módulos e documentos modificados no repositório. Esta operação

consiste em adicioná- las ao repositório (no caso mais simples), usando a funcionalidade do

gerenciador de controle de versão. Entretanto, sabemos que nem sempre será preciso

adicionar todos os arquivos ao repositório, deste modo, o gerenciador de workspaces deve ser


capaz de descobrir quais arquivos foram alterados e ter certeza de que somente estes serão

adicionados.

FIGURA 3.3 – REPRESENTAÇÃO DO GERENCIADOR DE WORSPACE (PASCUTTI, 2002)

O Gerenciador de Agentes é responsável pela criação, registro, localização,

migração e destruição de agentes.

O Repositório é responsável pelo armazenamento dos objetos, versões dos

documentos, produtos de software, dados das aplicações geradas pelo ADS (Ambiente de

Desenvolvimento de Software), bem como o conhecimento necessário para a comunicação

entre os agentes.

33..33 AA FFeerrrraammee nnttaa RREEQQUUIISSIITTEE

A ferramenta REQUISITE fornece suporte à MDSODI, no ambiente distribuído de

desenvolvimento DiSEN, na fase de requisitos, considerando aspectos de

concorrência/paralelismo, distribuição, sincronização e comunicação. Esta ferramenta auxilia

a concluir com êxito um acordo entre quem solicita e quem desenvolve software,

estabelecendo, clara e rigorosamente o que deverá ser produzido (BATISTA, 2003).

Segundo Batista (2003) um dos pontos positivos da REQUISITE é o uso de

técnicas baseadas em cenários. O conceito de cenários é facilmente compreendido pelos

diversos stakeholders2 (BREITMAN, 2003, 2004). Deste modo, auxilia no trabalho de

entendimento, negociação e validação dos requisitos de sistemas.

2 O termo stakeholder é utilizado para identificar qualquer pessoa que tenha interesse pelo sistema (ROBERTSON & ROBERTSON, 1999). Também conhecido como clientes potenciais (SANTANDER, 2002).

Workspace B

Workspace C Workspace A

Gerenciador

de Worspace

Canal de Comunicação

Repositório

Suporte à tarefa de

persistência


Elicitação de Requisitos

Gerenciamento dos Requisitos

Validação dos Requisitos

Análise e Negociação dos

Requisitos

Documentação dos Requisitos

A REQUISITE completa o comportamento do Universo de Informações do

Sistema (UdI), proporcionando um aumento de qualidade e redução no tempo e custo da

atividade de definição de requisitos.

FIGURA 3.4 – MODELO DE PROCESSO UTILIZADO NA REQUISITE. FONTE (BATISTA, 2003).

A Figura 3.4 apresenta o modelo de processo utilizado na construção da

ferramenta REQUISITE que é baseado no modelo de processo proposto por Kotonya &

Sommerville apud Batista (2003).

A elicitação dos requisitos é a fase inicial do processo, responsável por descobrir

os requisitos do sistema. As técnicas de modelagem de casos de uso, cenários e o Léxico

Extendido da Linguagem - LEL (LEITE, 1997) fornecerão um modelo das informações no

UdI. Nesta etapa, serão identificados os atores, os casos de uso, os cenários e LEL.

Na análise e na negociação dos requisitos são analisados os requisitos a fim de se

detectarem incompletudes, omissões e redundâncias.

A documentação de requisitos permite descrever as restrições quanto às

características do software, ao processo de desenvolvimento, a interface com outras

aplicações, a descrição sobre o domínio e as informações de suporte ao conhecimento do

problema. Serão produzidos o diagrama de casos de uso, cenário e LEL.

Na fase de validação de requisitos, será certificado se o documento de requisitos é

consistente com as necessidades dos usuários. Descrever os requisitos de forma explícita é


uma condição necessária não somente para validar os requisitos, mas também para resolver

conflitos entre usuários.

Gerenciar os requisitos diz respeito a poder escrever e acompanhar um requisito ao

longo de todo o processo de desenvolvimento, enquanto esse existir. Isso garante documentos

de requisitos mais confiáveis e gerenciáveis, aspectos importantes para a obtenção de

produtos de software de qualidade. Algumas das atividades da gerência de requisitos incluem

rastreamento de requisitos que podem ser executados através da exploração dos modelos,

utilizando-se, por exemplo, hipertexto.

33..33..11 AAssppeeccttooss FFuunncc iioonnaa iiss

A ferramenta apóia a modelagem de requisitos para a MDSODI, permitindo ao

engenheiro de requisitos criar e editar diagramas de casos de uso, cenários e LEL, bem como

rastrear requisitos. A Figura 3.5 apresenta o diagrama de casos de uso da ferramenta

REQUISITE.

FIGURA 3.5 – DIAGRAMA DE CASOS DE USO DA FERRAMENTA REQUISITE. FONTE (BATISTA, 2003).

De acordo com a figura 3.5 observamos as principais funcionalidades da

ferramenta REQUISITE:

construir hipertexto

construir cenário

<<include>>

salvar modelo

recuperar modelo

construir diagrama use case

construir LEL

<<include>>

explorar modelo

criar atorEngenheiro de requisitos

criar use case


a) Recuperar modelo – permite ao engenheiro de requisitos recuperar um

modelo localmente (workspace) ou no ambiente distribuído;

b) Salvar modelo - permite ao engenheiro de requisitos salvar um modelo

localmente (workspace) ou no ambiente distribuído DiSEN;

c) Criar casos de uso - permite ao engenheiro de requisitos adicionar,

modificar, consultar e remover um caso de uso ao modela. Os casos de uso previstos

pela MDSODI são aqueles descritos na Tabela 3.1;

d) Criar ator - permite ao engenheiro de requisitos adicionar, modificar,

consultar e remover um ator ao modelo. Os atores previstos pela notação da MDSODI

são aqueles descritos na Tabela 3.1;

e) Explorar modelo - esta funcionalidade permite ao engenheiro de

requisitos rastrear os cenários, entradas do LEL, atores, casos de uso e diagramas de

casos de uso;

f) Construir LEL - a engenheiro de requisitos, através desta funcionalidade,

poderá criar modificar, remover e consultar uma entrada na LEL do modela. A

primeira operação diz respeita à criação. de uma nova entrada na LEL, isto. é, a

identificação de um símbolo usada na linguagem da UdI. As operações de modificação e

remoção de uma entrada na LEL dizem respeita ao processo de construção do LEL que

é continuado;

g) Construir diagrama de casos de uso - permite ao engenheiro de

requisitos criar, construir, modificar, consultar ou remover um diagrama de casos de uso ao

modelo. Os relacionamentos previstos pela notação da MDSODI são aqueles descritos

na Tabela 3.1.

h) Construir cenário - e s t a funcionalidade permite ao engenheiro de

requisitos criar, modificar, consultar ou remover um cenário ao modelo.

A primeira operação diz respeito à criação e à introdução de um novo

cenário. De um modo geral, é o resultado da fase de elicitação e que acontece com

mais freqüência durante as etapas iniciais do processo. Não obstante, novos cenários

podem surgir em qualquer fase de desenvolvimento, pois lembramos que um sistema de


software faz parte de um sistema maior e dessa forma, estará sempre sujeita às

mudanças da ambiente ande está inserido.

A operação de modificação pode ser definida como um processo de

refinamento da informação codificada em um cenário. À medida que progride o

desenvolvimento de um sistema, aumenta a compreensão do ambiente onde este será

inserido e de seus requisitos. Durante esse processo, a informação capturada nas fases

iniciais vai sendo refinada de modo a refletir, mais precisamente, as necessidades do sistema.

Em conseqüência, o conteúdo dos cenários associados sofre modificações.

A operação de retirada consiste na exclusão de um cenário do modelo.

33..33..22 AA AArrqquuiitteettuurraa ddaa RREEQQUUIISSIITTEE

A arquitetura da ferramenta REQUISITE está apoiada em três camadas: interface,

software base e repositório. Na camada superior temos o software que faz a interface com os

engenheiros de requisitos. Através dessa camada, todas as interações com o sistema são

realizadas. Na camada base, temos o software responsável pelo processamento das

informações, ou seja, a lógica da aplicação. Na camada inferior temos o repositório que é o

responsável pelo armazenamento das informações, tais como diagrama de casos de uso,

atores, cenários e LEL.


A arquitetura detalhada da REQUISITE está representada na Figura 3.6 e as partes

constituintes da ferramenta são descritas a seguir:

FIGURA 3.6 – ARQUITETURA DETALHADA DA FERRAMENTA REQUISITE. FONTE (BATISTA, 2003).

a) Interface com o Engenheiro de Requisitos - é a responsável pela comunicação entre o

engenheiro de requisitos e a ferramenta, permitindo, com isso, o apoio no processo de

requisitos.

b) Construção Cenários - permite as operações de inclusão, modificação e retirada de

um cenário de um modelo.

c) Construção LEL - permite as operações de inclusão, modificação e retirada de uma

entrada no LEL.

Interface com Engenheiro de Requisitos

Construção

Cenários

Construção Hipertexto

Construção

LEL

Integração Casos de

uso/cenários

Suporte a persistência de artefatos

Criação Casos de

uso

Criação Relacio-namento

Criação Ator

Explorar Modelo

Construção Diagrama de Casos de uso

Suporte ao trabalho

cooperativo

Software base

Repositório


d) ConstruçãoHipertexto- gera elos de hipertexto entre o LEL e os cenários. Gera

também hipertexto entre um termo utilizado no LEL e uma entrada no LEL (princípio

da circularidade). Esta construção permite a rastreabilidade entre os modelos.

e) Criação de Caso de Uso - permite a adição, a remoção e a modificação de um caso

de uso.

f) Criação Ator - permite a adição, a remoção e a modificação de um ator.

g) Criação do Relacionamento - permite a adição, a remoção e a modificação de um

relacionamento em um diagrama de casos de uso. Os relacionamentos podem ser entre

casos de uso ou entre ator e caso de uso.

h) Construção Diagrama de Casos de Uso - cria e edita diagramas de use case. Isso

significa criação, a inclusão, a remoção, a modificação e a manipulação de atores, de

casos de uso e de relacionamentos no diagrama.

i) Integração de Casos de Uso / Cenário - cria, remove e modifica uma ligação entre

um caso de uso e um cenário. Através desta ligação, pode-se rastrear o cenário ligado

ao caso de uso.

j) Explorar Modelo - explora o modelo através de uma visão em forma de árvore

(TreeExplorer).

l) Suporte à Persistência de Artefatos - o suporte à persistência de artefatos permite

que um engenheiro de requisitos possa: armazenar, recuperar e remover artefatos de

um repositório de forma transparente. O suporte à persistência torna p o s sível

disponibilizar um repositório de metadados3 no ambiente distribuído de

desenvolvimento de software DiSEN, considerando requisitos que dizem respeito ao

acesso aos dados, disponibilidade, controle de versões, escalabilidade, transparência de

localização, recuperação de falhas, desempenho, sincronização, atomicidade das

operações e balanceamento de carga entre outros.

m) Suporte ao Trabalho Cooperativo - o suporte ao trabalho cooperativo é fornecido

através de elementos de percepção que capturam e condensam as informações

3 Metadados são considerados dados sobre dados. Podemos encontrar referencias a dados e metadados em Souza (2006).


coletadas durante a interação entre os participantes. O suporte ao trabalho cooperativo

fornece serviços de colaboração, o que torna possível a comunicação entre os

membros do grupo.

33..33..33 EExxeemmpplloo ddee IInnssttâânncc iiaass ddaa RREEQQUUIISSIITTEE nnoo DDiiSSEENN

A seguir, mostramos, na figura 3.7, um exemplo do funcionamento da ferramenta

REQUISITE, no ambiente DiSEN.

FIGURA 3.7 – ESQUEMA DE INSTÂNCIAS DA FERRAMENTA REQUISITE. FONTE (BATISTA, 2003).

No Workspace A, temos o Engenheiro de Requisitos X, com duas instâncias da

ferramenta REQUISITE em execução no DiSEN. No Workspace B, ternos o Engenheiro de

Requisitos Y, com uma instância da ferramenta REQUISITE em execução no DiSEN. Cada

instância da ferramenta REQUISITE utiliza um repositório de artefato local no seu workspace

e pode acessar, quando desejar, artefatos de um repositório de artefato distribuído no DiSEN.

Quando, por exemplo, o Engenheiro de Requisitos Y desejar alterar um artefato

que está no repositório distribuído, no caso mais simples, os serviços de suporte à persistência

do DiSEN fazem uma cópia deste modelo e o transfere para o repositório loca1. Após o

Engenheiro de Requisitos X Engenheiro de Requisitos Y

Workspace A Workspace B

Ferramenta

REQUISITE Ferramenta REQUISITE Ferramenta

REQUISITE

Interface Interface Interface

Lógica aplicação Lógica aplicação Lógica aplicação

Repositório local

de artefatos

Repositório local

de artefatos Repositório local

de artefatos

Repositório Distribuído de

Artefatos

Transfere

/atualiza

Transfere

/atualiza

Acessa/

Modifica

Acessa/

Modifica Acessa/ Modifica


término de seu trabalho, quando desejar, no caso mais simples, o Engenheiro de Requisitos

Y ativa os serviços de suporte à persistência do DiSEN e este atualiza o modelo no repositório

distribuído.

Desse modo, um grupo de stakeholders podem agregar diferentes tipos de

conhecimentos, habilidades e soluções e contribuir para que as atividades, sejam finalizadas

com um desempenho positivo.

FIGURA 3.8 – REPRESENTAÇÃO DA ARQUITETURA DO DISEN. FONTE (BATISTA, 2003).

Na representação dos elementos da arquitetura do DiSEN, ilustrado na figura 3.8,

destacamos que, em um workspace, na Camada de Aplicação, podem ser executadas várias

aplicações. Como exemplo, podemos citar: a própria ferramenta REQUISITE, o Distributed

Software Manager - DIMANAGER (PEDRAS, 2003) e/ou várias instâncias da mesma

aplicação como mostrado acima na Figura 3.7.

Camada de Aplicação (ferramentas)

Camada de Gerenciamento de Aplicação (distribuição/coordenação)

Camada de Abstração de Middleware

Middleware

Plataforma (Sistema Operacional, Computadores, Equipamentos de Rede)

Workspace 1 Workspace N

Aplicações Aplicações

Gerenciador de Objetos

Gerenciador de Agentes

Supervisor de Configuração

dinâmica Repositório

Gerenciador de

Workspace

Suporte à persistência

Suporte à nomeação

Suporte à transação

Suporte à Agentes

CORBA JINI RMI


33..44 RReessuummoo ddoo CCaappííttuulloo

Este capítulo apresentou a metodologia MDSODI e o ambiente DiSEN, como base

para o desenvolvimento da ferramenta REQUISITE.

Esta ferramenta identifica propriedades em um projeto de software, porém, é

importante salientar que propriedades é a principal característica que buscamos obter ao

desenvolvermos um projeto de software, ou seja, sempre esteve presente em nossos projetos.

Porém as propriedades transversais eram impossíveis de se mapear com as técnicas existentes

até então (CHITCHYAN et al, 2005).

Por este motivo, a ferramenta REQUISITE não está apta a identificar e representar

estas propriedades transversais (ou aspectos) utilizando a metodologia e a abordagem aplicada

a ela.

No próximo capítulo será apresentado uma nova abordagem para a Engenharia de

requisitos: a DAORE – Distributed Aspect Oriented Approach for Requirements Engineering.

4. A Abordagem DAORE 82

CAPÍTULO

44

A ABORDAGEM DAORE

A melhor forma de prever o futuro é criá-lo. Peter Drucker

ÉÉ iinntteerreessssaannttee oobbsseerrvvaarr ccoommoo aass mmeellhhoorreess iiddéé iiaass ssuurrggeemm ddee rreeppeennttee,,

ffooii aassss iimm ccoomm aallgguummaass iinnvveennççõõeess ee oouuttrraass ffoorraamm aattrraavvééss ddee

tteennttaatt iivvaa ee eerrrroo.. RReezzaa aa lleennddaa qquuee TThhoommaass AAllvvaa EEddssoonn,, oo iinnvveennttoorr

ddee vváárriiaass ccooiissaass ,, ddeennttrree ee llaass aa llââmmppaaddaa,, cceerrttaa ffeeiitt aa rreeuunniiuu sseeuuss

ccoollaabboorraaddoorreess ppaarraa uummaa ffeess ttaa.. AAoo cchheeggaarreemm,, ee sseemm ssaabbeerreemm qquuaall aa

rraazzããoo ddaa ccoommeemmoorraaççããoo,, ppeerrgguunnttaarraamm aa ee llee qquuee mmoott iivvooss ttiinnhhaa ppaarraa

ffaazzeerr uummaa ccoommeemmoorraaççããoo,, aaoo qquuee EEddssoonn rreessppoonnddeeuu:: ""ccoommeemmoorroo oo

ddéécc iimmoo mmiillééss iimmoo ffrraaccaassssoo nnaa mmiinnhhaa tteennttaatt iivvaa ddee iinnvveennttaarr aa

llââmmppaaddaa""..

““CCoommoo aassss iimm??”” PPeerrgguunnttaarraamm ooss pprreesseenntteess .. ““CCoommoo ppooddee aallgguuéémm

ccoommeemmoorraarr ddeezz mmiill ffrraaccaassssooss??””

““SSiimmpplleess ,, mmeeuuss ccaarrooss””,, rreessppoonnddeeuu EEddssoonn:: ""SSoouu aa úúnniiccaa ppeessssooaa nnoo

mmuunnddoo qquuee ccoonnhheeccee ddeezz mmiill mmaanneeiirraass ddiiffeerreenntteess ddee ccoommoo nnããoo ffaazzeerr

uummaa llââmmppaaddaa!! IIssssoo mmeerreeccee uummaa ccoommeemmoorraaççããoo!!""..

NNaa ddéécc iimmaa mmiillééss iimmaa pprriimmeeiirraa tt eennttaa tt iivvaa ee llee iinnvveennttoouu aa llââmmppaaddaa!!


AAnnaallooggaammeennttee aaoo ddeesseennvvoollvviimmeennttoo ddee ss iiss tteemmaass ,, tteemmooss pprrooccuurraaddoo

oobbsseerrvvaarr oouuttrraass cc iiêênncciiaass ee ttrraazzeerr aa llgguunnss ccoonncceeiittooss ppaarraa,, nnoo mmíínniimmoo,,

ffaacc iilliittaarr nnoossssaa ccoommpprreeeennssããoo ssoobbrree oo pprroobblleemmaa ee ffoorrmmuullaarr ssoolluuççõõeess ..

PPoorréémm,, ssaabbeemmooss qquuee uumm mmeessmmoo ss iiss tteemmaa ddee ssooffttwwaarree ppaarraa eemmpprreessaass

ddiiffeerreenntteess rreeqquueerr ppeeqquueennaass mmooddiiff iiccaaççõõeess ((nnooss ccaassooss mmaaiiss ss iimmpplleess ))

ee,, ààss vveezzeess ,, ggrraannddeess mmuuddaannççaass ..

DDeess ttee mmooddoo,, oo ddeesseennvvoollvviimmeennttoo ddee ss iiss tteemmaass ddee ssooffttwwaarree,, mmaaiiss

ppaarrttiiccuullaarrmmeennttee oo qquuee cchhaammaammooss ddee EEnnggeennhhaarr iiaa ddee RReeqquuiiss iittooss

ccoommpprreeeennddee uummaa ddaass mmaaiiss ccoommpplleexxaass aatt iivviiddaaddeess ddaa EEnnggeennhhaarr iiaa ddee

SSooffttwwaarree..

DDuurraannttee oo pprroocceessssoo ffoorraamm ppeessqquuiissaaddaass ee uuttiilliizzaaddaass vváárr iiaass ssoolluuççõõeess ,,

ppoorréémm sseemmpprree hhaavveerráá oo aappeerrffeeiiççooaammeennttoo ddee mmééttooddooss ,, bbuussccaannddoo uummaa

mmeellhhoorr iiaa ccoonnttíínnuuaa..

AA aabboorrddaaggeemm pprrooppooss ttaa aa sseegguuiirr bbuussccaa eexxaattaammeennttee iissssoo:: uummaa ssoolluuççããoo

ppaarraa aallgguunnss pprroobblleemmaass ((ddeennttrree ooss mmuuiittooss)) ddaa áárreeaa ddee EEnnggeennhhaarr iiaa ddee

RReeqquuiiss iittooss OOrriieennttaaddaa aa AAssppeecc ttooss ..

44..11 OObbjjeett iivvooss ee DDiirreettrriizzeess PPrriinncc iippaaiiss

A Abordagem DAORE – Distributed Aspect Oriented Approach for

Requirements Engineering, tem como principal objetivo facilitar a identificação de

aspectos candidatos nas fases iniciais do processo de desenvolvimento de sistemas. Para

isso, se utiliza de conceitos e ferramentas gráficas de algumas abordagens existentes (as

estudadas no Capítulo 2), além de propor um novo modelo de processo.

A tabela 4.1 apresenta os conceitos e ferramentas utilizadas das abordagens

anteriores na abordagem DAORE.


TABELA 4.1 –. CONCEITOS E ARTEFATOS USADOS NA DAORE

Abordagens AORE Estudadas Características Viewpoint Goals Use Case Theme/Doc

Relacionamento entre aspectos e requisitos funcionais

Adaptado para requisitos não funcionais e funcionais

Operacionalizações de requisitos não funcionais

Adaptado para estratégias de satisfação. Utiliza-se este conceito também nos requisitos organizacionais.

Identificação dos aspectos

Adaptado de Clarke&Baniassad (2005)

Composição dos aspectos

Utiliza-se o modelo proposto por Souza (2004)

Resolução de conflitos nos aspectos

Utiliza-se o modelo proposto por Souza (2004)

No capítulo 2 foi feita uma comparação entre estas abordagens e partindo desta

premissa definimos algumas diretrizes que a DAORE deve possuir:

· A - Suporte a metodologia MDSODI na definição dos cenários e das

propriedades transversais – pois esta metodologia é a utilizada pelo ambiente

DISEN e pela ferramenta REQUISITE, por este motivo a abordagem recebeu

em sua definição o nome de Distributed;

o Para tornar esta correlação mais clara nos projetos foi identificado nos

cenários o seu tipo de acordo com a proposta da MDSODI; e

o Esta identificação facilita a forma de tratamento dos cenários nas fases

seguintes ao desenvolvimento.

· B - Permitir um alto grau de usabilidade (de acordo com o conceito introduzido

pela Tabela 3.9 do Capítulo 3);


· C - Boa adequação quanto à identificação de propriedades transversais;

· D - Facilitar a identificação de propriedades transversais não-funcionais,

derivados de requisitos não funcionais, a partir do trabalho do Cysneiros (2001)

e das normas ISO/IEC 9126;

· E - Identificar e modelar requisitos organizacionais, através de suas

operacionalizações (quando pertinentes ao domínio);

· F - Aumentar a apreensabilidade através da identificação das propriedades

transversais;

· G – Especificar XML Schemas1 para auxiliar na exportação de documentos

padrão no formato XML (símbolos do LEL, cenários, aspectos e ontologias), a

fim de aumentar a interoperabilidade entre ferramentas utilizadas pela

MDSODI;

· H - Facilitar a resolução de conflitos manualmente através de padrões de

domínio pré-estabelecidos – reuso de especificações e ontologias2 de requisitos

utilizando o LEL, e

· I – Facilitar o rastreamento de requisitos através do principio de circularidade

(utilizado no LEL) e vocabulário mínimo.

A Tabela 4.2 apresenta a relação das diretrizes em relação às características de

qualidade apresentadas na Tabela 2.8 e 2.9 do Capítulo 2.

O seu preenchimento está de acordo com as definições apresentadas

anteriormente. Assim foi feito à atribuição das diretrizes onde elas melhor se

aproximavam da definição.

1 Alguns XML Schemas estão especificados pela W3C em www.w3c.org , porém não há especificação para requisitos e o LEL. 2 Alguns conceitos de ontologias podem ser encontrados em Breitman (2005).


TABELA 4.2 –. RELAÇÃO ENTRE DIRETRIZES DA DAORE E AS CARACTERÍSTICAS DE QUALIDADE

Característica Sub-característica Diretriz Abrangência A Adequação C Acurácia D, G Interoperabilidade G

Funcionalidade

Conformidade D, G, H Confiabilidade Maturidade F

Artefatos A, D,G Apoio Case A, B,C,D e G Inteligibilidade A, B, D, E, H

Usabilidade

Apreensibilidade F Resolução de Conflitos H Tratamento de Requisitos Organizacionais

E

Requisitos funcionais – aspectos F

Eficiência

Requisitos não funcionais – aspectos D, F

Rastreabilidade I Analisabilidade H Modificabilidade I

Manutenibilidade

Testabilidade A Adaptabilidade G Capacidade para ser instalada G Portabilidade Capacidade para substituir A

Como podemos observar na tabela 4.2, nos itens:

· Abrangência: foi atribuída a diretriz A, pois como a abordagem deve

apoiar a MDSODI na fase de requisitos.

· Adequação: foi atribuída a diretriz C, pois deve possuir boa adequação

quanto a identificação e composição de propriedades transversais.

· Acurácia: foram atribuídas a s diretrizes D e G, pois deve facilitar a

identificação de propriedades e dos requisitos não funcionais através de

ontologias sugeridas por Cysneiros (2001), além de definir padrões

para permitir a importação de documentos.

· Interoperabilidade: foi atribuída a diretriz G, pois deve possuir a

capacidade de interagir com ferramentas diferentes através da

importação de documentos seguindo uma padronização.


· Conformidade: foram atribuídas as diretrizes D,G e H, pois a

conformidade diz respeito a padrões e, sendo assim, deve estar de

acordo com o estabelecido.

· Maturidade: foi atribuída a diretriz F, pois o aprendizado através do

auxilio da identificação de propriedades proporcionada pela abordagem

permite o aumento de maturidade uma vez que pode ser feito de forma

semi-automática.

· Artefatos: foram atribuídas as diretrizes A,D e G, pois contém os

artefatos previstos para a definição do LEL, além de ontologias de

requisitos não funcionais e de documentos XML.

· Apoio Case: foram atribuídas as diretrizes A,B,C,D e G, pois deve

oferecer suporte a metodologia MDSODI na construção dos cenários,

na especificação dos propriedades transversais, nos requisitos não

funcionais, na utilização da abordagem e na confecção de documentos

XML.

· Inteligibilidade: foram atribuídas as diretrizes A,B,D,E e H, pois os

conceitos e definições da abordagem serão mais consistentes e mais

fáceis de compreender se for feito de forma semi-automática (de

preferência de forma automática), assim está ligada ao item anterior

também.

· Apreensibilidade: foi atribuída a diretriz F, pois o objetivo principal da

abordagem está na facilidade de identificação dos propriedades

transversais, porém podemos atribuir o item anterior também.

· Resolução de Conflitos: foi atribuída a diretriz H. Infelizmente a

resolução de conflitos deve ser realizada de forma manual, mas

podemos identificar os conflitos de forma automática.

· Tratamento de Requisitos Organizacionais: foi atribuída a diretriz E,

pois deve permitir a integração dos requisitos organizacionais com os

requisitos funcionais através de suas operacionalizações.


· Requisitos funcionais – aspectos: foi atribuída a diretriz F, pois deve

possuir diretrizes para nortear a identificação dos requisitos funcionais

como propriedades transversais.

· Requisitos não funcionais – aspectos: foram atribuídas as diretrizes D e

F, pois deve possuir diretrizes para nortear a identificação dos

requisitos não funcionais como propriedades transversais.

· Rastreabilidade: foi atribuída a diretriz I, pois através do principio de

circularidade do LEL podemos realizar o rastreamento de requisitos.

· Analisabilidade: foi atribuída a diretriz H, pois através da resolução de

conflitos podemos identificar possíveis “falhas” na composição das

propriedades transversais.

· Modificabilidade: foi atr ibuída a d i r e t r i z I, p o i s através do

rastreamento permitido pelo principio de circularidade do LEL

podemos identificar e atualizar mais rapidamente as informações, bem

como analisar e detectar possíveis erros.

· Testabilidade: foi atribuída a diretriz A, pois deve estar de acordo com

a MDSODI na definição dos cenários a fim de permitir o seu uso.

Podemos também identificar uma forte ligação com o Apoio Case para

o cumprimento desta característica.

· Adaptabilidade: foi atribuída a diretriz G. A adaptabilidade diz respeito

a instalação, mas como estamos lidando com abordagem podemos

dizer que esta deve ser capaz de se adaptar a novos ambientes com o

mínimo de esforço. Este princípio pode ser satisfeito com a exportação

de documentos em XML.

· Capacidade para ser instalada: foi atribuída a diretriz G, pois pode ser

exportado o documento XML para ser importado em outro ambiente.

· Capacidade para substituir: foi atribuída a diretriz A, pois deve

possuir integração com a MDSODI com o mínimo esforço na mudança

ocorrida.


44..22 OO PPrroocceessssoo ddee DDeesseennvvoollvv iimmeennttoo PP rrooppoossttoo

A DAORE possui o modelo de processo de desenvolvimento baseado na Figura

4.1. Este modelo de processo procura seguir o modelo geral da Engenharia de Requisitos

proposto por (KOTONYA e t a l apud SANTANDER, 2002), porém com algumas

adaptações para incorporar os trabalhos de Cysneiros (2001) e Breitman (2003, 2005),

além de incorporar a definição de aspectos candidatos para abranger as diretrizes

propostas anteriormente.

FIGURA 4.1 –. MODELO DE PROCESSO DA ABORDAGEM DAORE

De modo geral as fases de desenvolvimento do processo especificadas na

figura 4.1 estão descritas como se segue:

Fase 1 - Construção de Requisitos – deve-se seguir a construção dos requisitos

funcionais, não funcionais e organizacionais;

Fase 2 - Construção do LEL – deve-se seguir a construção dos termos do LEL

e dos cenários elicitados;

Fase 3 – Definição dos Aspectos Candidatos – deve-se definir os aspectos

candidatos baseados em algumas diretrizes propostas; e

Fase 4 – Mapeamento de Ontologias – deve-se realizar o mapeamento de

ontologias seguindo um padrão proposto por Breitman (2005).

As fases 3 e 4 independem uma da outra, podendo ser construídas em

paralelo.A seguir descreveremos o processo de construção de cada fase.

Construção de Requisitos

Construção do LEL

Definição de Aspectos Candidatos

Mapeamento de Ontologias


Levantamento

dos requisitos

Utilização de técnicas

tradicionais

Análise e Negociação

Lista Requisitos

iniciais

Lista Requisitos

Refinados

Refinamento dos Requisitos e

Entendimento do Problema

Requisitos do Sistema

Está

satisfeito

Validação com

cliente

44..22..11 FFaassee 11 –– CCoonnssttrruuççããoo ddee RRee qquuiissiittooss

De um modo geral na construção dos requisitos devemos identificar os

requisitos organizacionais (dizem respeito a metas da empresa, suas políticas estratégicas

adotadas, os relacionamentos entre os seus atores junto com seus respectivos objetivos),

requisitos funcionais (definem a funcionalidade do sistema) e requisitos não funcionais

(dizem respeito a questões de qualidade e segurança, de maneira geral).

4.2.1.1 - Levantamento dos Requisitos

A construção de requisitos segue o modelo proposto por Kotonya et al apud

Santander (2002), figura 4.2.

FIGURA 4.2 – PROCESSO GERAL DE CONSTRUÇÃO DE REQUISITOS

Podemos observar que o processo geral de construção de requisitos (figura 4.2)

inicia-se com o levantamento dos mesmos através de técnicas tradicionais como

entrevistas, cenários (HADAD et al. 1999) (HAUMER et al. 1998) (LEITE et al. 1997)

(BREITMAN et al. 1998); observação e análise social (GOGUEN et al. 1993); etnografia

(SOMMERVILLE et al. 1999); entre outras. Toda técnica de elicitação deve descrever os

requisitos através de uma representação facilmente entendida por todos os stakeholders

(SANTANDER, 2002).


Após a elicitação dos requisitos eles devem ser analisados para detectar

incompletudes, omissões ou redundâncias. Na análise, a preocupação está em descobrir os

requisitos que realmente são necessários e que o stakeholder deseja. Santander (2002)

descreve ainda algumas técnicas utilizadas para realizar análise dos requisitos.

Santander (2002) define a negociação dos requisitos como sendo uma atividade

que visa solucionar problemas advindos de conflitos entre os diversos stakeholders, os

quais podem atribuir diferentes prioridades aos requisitos. A negociação consiste em que

todos os stakeholders entrem em consenso em relação a um conjunto de requisitos

definidos, bem como em relação às prioridades definidas para os mesmos.

A atividade de validação de requisitos é a última atividade para certificar-se

que o documento final de requisitos satisfaz em todos os aspectos o que o usuário deseja

do sistema. Santander (2002) descreve técnicas de validação onde são refinados os

requisitos até que tenhamos uma lista dos requisitos acordados.

Em nosso trabalho exploraremos um pouco mais os conceitos referentes aos

requisitos não funcionais e organizacionais, uma vez que os requisitos funcionais são mais

simples de serem identificados, mesmo porque, é a razão de existência do projeto a ser

desenvolvido.

4.2.1.2 - Construção de Requisitos Funcionais

Os requisitos funcionais dizem respeito à definição das funções que um sistema

ou um componente de sistema deve fazer. Eles descrevem as transformações a serem

realizadas nas entradas de um sistema ou em um de seus componentes, a fim de que se

produzam saídas (SANTANDER, 2002).

A identificação dos requisitos funcionais pode ser realizada seguindo técnicas

existentes para a elicitação de requisitos: entrevistas, cenários (LEITE et al., 1997)

(HADAD et al., 1999) (HAUMER et al., 1998) (BREITMAN & LEITE, 1998),

observação e análise social, entre outras. Neste trabalho segue a técnica de cenários

proposto por (LEITE et al., 1997).

4.2.1.3 - Construção de Requisitos não-Funcionais

A identificação de requisitos não funcionais diz respeito, geralmente, a

questões de qualidade e segurança. A sua identificação pode ser realizada tendo por base

as características de qualidade do software, definidos por meio da ISO/IEC 9126 (ISO,


2006). Assim podemos definir para nossos projetos, baseados no domínio da aplicação,

características afins e sub-características, perfazendo um banco de ontologias de domínio

para requisitos não funcionais.

A autora deste trabalho acredita que, por exemplo, se definirmos inicialmente

um conjunto de requisitos não funcionais baseados em um domínio de uma aplicação

médica, é bem provável que sejam utilizados em uma outra aplicação de um mesmo

domínio.

Assim, o trabalho do Engenheiro de Requisitos pode ser apoiado por este

poderoso aliado na elucidação de requisitos não funcionais.

Algumas classificações dos RNFs podem ser encontradas na literatura:

(MAMANI, 1999), (SOMMERVILLE, 92) e (CYSNEIROS, 2001). Neste trabalho iremos

utilizar a classificação do Cysneiros, por se utilizar do Chung (2000) e das normas

ISO/IEC 9126, para construção de nosso banco de requisitos não funcionais.

Um fator muito importante na elicitação dos requisitos não funcionais é que

são geralmente muito abrangentes, como nos trabalhos das abordagens anteriores, como

(BRITO & MOREIRA, 2003) (JACOBSON & NG, 2005) (RASHID et al., 2002)

(ARAUJO et al., 2002). Assim, a classificação proposta por Cysneiros elaborando a

decomposição dos RNF em operacionalizações resulta em um trabalho mais minucioso.

Cysneiros (2001) propõe uma taxonomia que classifica os RNFs em primários

e específicos (ver figura 4.3). RNFs primários são aqueles mais abstratos que representam

propriedades como: Confiabilidade, Rastreabilidade, Precisão, Segurança. Já os RNFs

específicos são decomposições que se seguem aos RNFs primários e tendem a diminuir o

nível de abstração de um determinado RNF, e portanto, atingir um nível de granularidade

no tratamento da informação mais detalhado.

Um exemplo desta classificação seria o RNF Primário Confiabilidade que pode

ser decomposto em validação, autorização e entrega do software.

RNFs primários podem ser decompostos em outros RNFs secundários até que

se chegue ao que Chung (CHUNG, 2000) chama de operacionalização dos RNFs. Uma

operacionalização de um RNF é uma ação ou informação que irá garantir a satisfação do

RNF.


Cysneiros (2001) exemplifica o caso de um sistema de informação para

laboratórios de análises clínicas. A entrega do laudo ao paciente possui um RNF de

confidencialidade que seria seu RNF primário. Para que possamos detalhar o que isso

implica, temos de decompor este RNF em um RNF específico de segurança operacional

que por sua vez poderia ser decomposto na operacionalização solicitar carteira de

identidade. Ou seja, para satisfazer o RNF confidencialidade teríamos de prever uma ação

no sistema, que garantisse que o funcionário que entregou o laudo solicitou a carteira de

identidade ao paciente antes de entregar-lhe o laudo.

FIGURA 4.3 – UMA TAXONOMIA PARA RNFS. FONTE: CYSNEIROS(2001)

RNFs Dinamicos

Tempo real Performance ** Restrições de tempo

Outras Clareza da Informação Custo Seguro Qualidade Restrições Operacionais Restrições Físicas

Fácil de achar onde está um erro

Manutenabilidade ** Fácil de modificar

Estáve

Fácil de testar

Portabilidade ** Adaptabilidade

Fácil de migrar por plataformas

Usabilidade ** Fácil de aprender

Fácil de Usar (interface adequada)

Confiabilidade ** Equipamento/Informação dispnível quando necessário

Integridade

Maturidade

RNF Estático

Numerica Precisão Informação correta sempre disponível

Rastreabilidade

Confidencialidade Identidade confirmada Dados privados não espostos

Qualidade

Validação Confiabilidade Autoriazação

Entrega

Permissão para consultar/atualizar informação Segurança

Confidencialidade de dados

RNF Primário RNF Específico

** ISO 9126

Caminho feito por algo/alguém Qual o estado no momento

Tipo de equipamento a ser utilizado Ordens de exibição específicas


De acordo com a figura 4.3, Cysneiros separa os RNFs em estáticos e

dinâmicos. RNFs estáticos são aqueles que, quando presentes, normalmente requerem o

uso de dados para validá- los como, por exemplo: segurança, precisão e rastreabilidade.

RNFs dinâmicos, por outro lado, usualmente representam conceitos mais abstratos, que

normalmente envolvem ações ou critérios de qualidade como, por exemplo:

Qualidade, performance, manutenibilidade, restrições operacionais. Alguns RNFs podem

ser tanto estáticos quanto dinâmicos dependendo do contexto do domínio que estejam

inseridos. A Figura 4.3 mostra um resumo desta taxonomia que também pode ser utilizada

como um checklist para a elicitação de RNFs.

Utilizaremos a Tabela 4.3, adaptada da ferramenta OORNF, desenvolvida no

trabalho de Cysneiros (2001) para identificar uma ontologia de RNF inicial. Esta tabela

possui os requisitos primários e secundários do sistema, bem como sua estratégia de

satisfação, Influência (I) e uma observação indicando o porque da influencia positiva(+)

ou negativa (-) da estratégia de satisfação no RNF.

Cysneiros (2001) afirma ainda que esta lista não pretende ser completa, mas

sim, um ponto de partida para cada desenvolvedor gerar seu próprio conhecimento a

respeito de RNFs, podendo inclusive adicionar outros.

TABELA 4.3 – RNFS E ESTRATÉGIAS DE SATISFAÇÃO. FONTE: CYSNEIROS(2001).

RNF Primário

RNF Específico

Estratégia Satisfação

I Observações

Informação de apoio

+ caso as informações de apoio sejam utilizadas para a obtenção de precisão de valor de outros itens de informação.

validação + pois a inspeção das informações por uma pessoa diferente do emissor aumenta a possibilidade de descobrir valores incorretos destas informações.

Precisão - auditoria

+ caso os itens de informação recuperados e verificados tenham uma precisão de valor duvidosa.

Validação automática

+ pois inspeciona itens de informação em relação a informações de apoio para verificar se estão corretos.

Faixa de valores + caso sejam adotados procedimentos para impedir que itens de informação assumam valores fora da faixa ou para autorizar que itens de informação tenham valores fora da faixa.

Aviso - Valor impreciso

+ caso o aviso chame atenção sobre itens de informação com valor duvidoso.

PR

EC

ISÃ

O

PR

EC

ISÃ

O D

E V

AL

OR

autorização + pois a presença de um autorizador dificulta


que itens de informação incorretos sejam transmitidos para o sistema de informação.

Capacidade de executar tarefa

+ pois a capacidade/nível de confiança do ator do UdI aumenta a precisão de valor dos itens de informação que manipula

confirmação + pois os itens de informação indicados são comparados para verificar sua correção.

Pré-aviso de valor impreciso

+ caso se indique ações que possibilitam evitar valores incorretos

Validação na fonte

+ pois os itens de informação com precisão de valor duvidosa são verificados em suas fontes

Checar consistência

+ caso as restrições de integridade estejam relacionadas com precisão de valor de itens de informação.

Apoio a informação

+ caso as informações de apoio sejam utilizadas para a obtenção de precisão de valor de outros itens de informação.

validação - caso seja necessário um tempo excessivo para a validação.


+ caso os itens recuperados e verificados tenham uma precisão de oportunidade duvidosa.


+ pois é mais rápida do que a validação convencional.

Validação de acesso

- caso a validação das regras de acesso seja demorada.

Aviso de valor impreciso

+ caso aviso chame atenção sobre itens de informação que estão atrasados para serem divulgados ou repassados

autorização - caso o processo de autorização sejam demorado ou o autorizador não esteja sempre disponível para realizar a autorização.

calendário + pois a definição de prazos aumenta a probabilidade dos itens de informação serem indicados no tempo correto.

Pre

cis

ão

de

op

ort

un

ida

de


+ caso se indiquem ações que possibilitem evitar atrasos na indicação de itens de informação


+ caso as informações de apoio sejam utilizadas para a obtenção de precisão de propriedade de outros itens de informação.

validação + pois a inspeção das informações por uma pessoa diferente do emissor aumenta a possibilidade de descobrir propriedades desejadas destas informações, que não estão presentes.


+ caso os itens de informação recuperados e verificados tenham uma precisão de propriedade duvidosa.


+ pois inspeciona itens de informação, utilizando informações de apoio, para verificar se possuem determinadas propriedades.

Pre

cis

ão

de

pro

prie

da

de

Faixa de valores + caso sejam adotados procedimentos, como por exemplo autorização, para garantir certas propriedades de itens de informação que estejam fora da faixa.


autorização + pois a presença de um autorizador dificulta que itens de informação, que não possuem uma propriedade desejada, sejam transmitidos para o sistema de informação.

Capacidade de executar tarefa

+ pois a capacidade/nível de confiança do ator do UdI aumenta a precisão de propriedade dos itens de informação que manipula


+ caso se indiquem ações que possibilitem evitar que certas propriedades não estejam presentes em itens de informação

Validação na fonte

+ pois os itens de informação com precisão de propriedade duvidosa são verificados em suas fontes

Checar consistência

+ caso as restrições de integridade estejam relacionadas com alguma(s) propriedade(s) de itens de informação que se deseja alcançar

Qualidade impressão

+ onde a propriedade desejada é qualidade de impressão de itens de informação.

Consistência externa


+ caso se indique ações que possibilitem evitar que os itens de informação não estejam refletindo seus valores do mundo real

validação - caso o validador não possa ter acesso às informações validadas.

Identificação/autorização

+ pois, com a identificação e autenticação das identidades dos atores do UdI, pode-se permitir o acesso às informações, recursos, e/ou atores do UdI apenas para os atores que tem permissão para tal.


- caso os auditores não possam ter acesso às informações recuperadas e verificadas.

Tempo limitado de acesso

+ pois limita o tempo para acessar itens de informação

Histórico de acesso

+ pois permite identificar acessos não autorizados a itens de informação.

alarme + pois permite a detecção de acessos não autorizados a itens de informação.


+ pois os itens de informação são acessados apenas por quem tem direito para tal.

Segurança - auditoria

+ pois permite detectar acessos não autorizados a itens de informação.

identificação + pois, com a identificação, é possível permitir o acesso às informações, recursos e/ou atores do UdI apenas para os atores que tem permissão para tal

confidencia

bili

dade

autenticação + pois, com a autenticação, pode-se permitir acesso às informações, recursos e/ou atores do UdI apenas para os atores do UdI que tem permissão para tal e asseguram suas identidades

Identificação/ autorização

+ pois, com a identificação e autenticação das identidades dos atores do UdI, pode-se permitir a alteração de informações apenas para os atores que tem permissão para tal.


+ pois limita o tempo para alterar itens de informação.

se

gu

ran

ça

inte

gridade


+ pois permite identificar alterações não autorizadas a itens de informação.


Alarme + pois ajuda na detecção de alterações não autorizadas de itens de informação.


+ pois os itens de informação são alterados somente por quem tem direito para tal.


+ pois permite detectar alterações não autorizadas de itens de informação.

identificação + pois, com a identificação, pode-se permitir a alteração de itens de informação apenas para atores do UdI que tem permissão para tal

autenticação + pois, com a autenticação, pode-se permitir alteração de informações apenas para os atores do UdI que tem permissão para tal e asseguram suas identidades

Disponibilida-de


- pois os serviços do sistema de informação são suspensos após um determinado tempo.

Identificação/ autorização

- caso sejam necessárias várias identificações e autenticações.

Aviso de imprecisão

- caso os avisos sejam freqüentes, atrapalhando a utilização dos serviços do sistema de informação por atores do universo de informações.

confirmação - caso o mesmo ator do UdI deva informar duas vezes o mesmo item de informação.

identificação - caso seja necessário realizar a identificação várias vezes.

rapid

ez

autenticação - caso seja necessário realizar a autenticação várias vezes.

Usabili

dade

Taxa baixa de erros

Faixa de valores + caso sejam adotados procedimentos que avisem que valores de itens de informação digitados estão fora da faixa.

confiabilidade

Confiabilida-de na

execução de tarefas

Habilidade na execução de tarefas

+ pois o ator do universo de informações tem conhecimento e/ou nível de confiança para executar ação.

auditoria - caso seja necessário a contratação de pessoas para realizar a auditoria.

autorização - caso seja necessário a contratação de pessoas para realizarem o papel de autorizadores.

Capacidade na execução

- caso seja necessário contratar mais pessoas que tenham o conhecimento e/ou confiança para executar as ações.

confirmação - Validação na fonte

- caso o contato com a fonte dos itens de informação seja caro

custo

Cu

sto

op

era

cio

na

l

Qualidade na impressão

- caso os recursos, utilizados para atingir qualidade de impressão, sejam caros.


- caso seja demorado o registro das informações do histórico.

Tempo de performance


- caso a manutenção do histórico acarrete uma diminuição na rapidez dos serviços prestados pelo sistema de informações.

Espaço - performance


- caso as informações de apoio sejam numerosas.

perf

orm

ance

Tempo e local – rastreabilida-de


+ pois registra o autor de consultas e alterações de itens de informação, bem como quando aconteceram as consultas e alterações


A tabela 4.3 apresentou uma ontologia de requisitos não funcionais, indicando

a influência da estratégia de satisfação utilizada para atender ao requisito de forma geral,

ou seja, se possui uma influência negativa (-) ou positiva (+).

Se houver a necessidade, ao final das operacionalizações dos requisitos não

funcionais, uma tabela pode servir de apoio para o mapeamento dos requisitos não

funcionais e funcionais, conforme pode ser verificado na Tabela 4.4.

TABELA 4.4 –. MAPEAMENTO DOS REQUISITOS NÃO FUNCIONAIS E REQUISITOS FUNCIONAIS

Requisitos Funcionais Requisitos Não Funcionais

RF1 RF2 ... RFn

RNF1 X RNF2 X ... RNFn

Cysneiros (2001) relaciona as operacionalizações dos requisitos não funcionais

ao LEL a partir de seus símbolos (ou termos), porém relacionaremos ao construirmos os

cenários, pois na construção dos cenários isso é repetido. Esta tarefa será explicada com

mais detalhes ao verificarmos a fase 3 – Construção do LEL.

4.2.1.4 - Construção de Requisitos Organizacionais

Geralmente a Identificação de Requisitos Organizacionais é descartada, porém

já se tem trabalhos salientando a importância de sua elaboração e integração na

modelagem funcional (SANTANDER, 2002).

O conhecimento do ambiente organizacional permite definir como o sistema de

software pretendido irá satisfazer os objetivos da organização, porque ele é necessário,

quais as alternativas existentes e quais as implicações das alternativas para as várias partes

interessadas, entre outros aspectos (SANTANDER, 2002).

Toranzo (2002) expõe que os objetivos dos modelos organizacionais são:

1) Entender a estrutura e a dinâmica da organização que hospedará o sistema;

2) Entender os problemas da organização e identificar as suas soluções;


3) Obter uma única e melhor compreensão da organização;

4) Contribuir para derivar requisitos do sistema para apoiar a organização.

Portanto, uma cuidadosa atenção aos aspectos organizacionais é crucial para o

sucesso do sistema de informação de uma organização (YU, 1997).

A inclusão da modelagem organizacional torna explícito o fato de que podem

existir alguns conceitos organizacionais que são importantes para identificar e conhecer as

implicações sobre os requisitos dos sistemas.

Santander (2002) argumenta que a visão tradicional em Loucopoulos &

Karakostas (1995) esquece aspectos importantes que influenciam diretamente no sistema

que se deseja especificar, tais como: objetivos do sistema e seu relacionamento com os

objetivos da organização e outras propriedades relacionadas com o desempenho,

segurança e restrições.

De qualquer forma, os requisitos organizacionais são importantes porque

auxiliam a compreensão de interações complexas entre as organizações e pessoas

envolvidas.

No RUP – Rational Unified Process, a modelagem organizacional está definida

no Workflow de Modelagem de Negócio, cujo objetivo principal está em modelar a

organização. Para isso define o modelo de casos de uso de negócio e o modelo de objetos

de negócio.

O modelo de casos de uso de negócio representa as funções de negócio

desejadas. Consiste de atores e casos de uso no nível de negócio. Os atores representam

papeis externos em relação a um negócio e casos de uso de negócio são processos.

O modelo de objetos de negócio inclui realizações de casos de uso, as quais

mostram como casos de uso de negócio são executados, em termo de interações de

trabalhadores de negócio e entidades de negócio.

O modelo de negócios e o modelo de casos de uso de negócio podem auxiliar

na identificação da relevância destes aspectos.

Algumas situações são mais visíveis para identificar quando um requisito

organizacional é relevante para o sistema de software a ser desenvolvido. Por exemplo, a

gerência de um supermercado pode decidir que o sistema de venda de produtos


implantado, deverá incluir um processo de atribuição de pontos aos clientes que possuam

o cartão de fidelidade do supermercado.

Assim, identificar os requisitos organizacionais, suas prioridades, suas

expectativas em relação ao sistema podem levar à definição de algumas funcionalidades

na qual o sistema deve atender para que possa satisfazer estes requisitos organizacionais.

Estas funcionalidades dizem respeito a uma restrição ou influência em relação

a uma funcionalidade básica.

Uma maneira mais simples de identificação seria após a identificação dos

requisitos organizacionais (e sua possível decomposição) formular algumas perguntas

chaves, como:

1) Este requisito influencia outros requisitos? Quais?

2) Ele é possível de implementação?

Assim, ao determinar os requisitos organizacionais do sistema e sua possível

operacionalização fica mais fácil identificar quais requisitos serão afetados se existir um

mapeamento dos requisitos organizacionais com os requisitos funcionais e não funcionais,

como podemos observar na tabela 4.5.

TABELA 4.5 – MAPEAMENTO DOS REQUISITOS ORGANIZACIONAIS EM REQUISITOS FUNCIONAIS E NÃO

FUNCIONAIS

Requisitos Funcionais Requisitos não funcionais

Requisitos Organizacionais

RF1 RF2 ... RFn R1 R2 ... Rn

RO1 X RO2 X X ... ROn

44..22..22 FFaassee 22 –– CCoonnssttrruuççããoo ddoo LLEELL

Este recurso foi implementado na ferramenta REQUISITE e será, igualmente,

utilizado na abordagem DAORE.

O principal objetivo do Léxico Ampliado da Linguagem (LAL) ou Léxico

Extendido da linguagem (LEL) é o de registrar a linguagem utilizada pelos atores do UdI,


Sim Não

Não Sim

Formatar texto Identificação dos símbolos

Texto formatado

Inclusão, Classificação e descrição dos

símbolos

Requisitos do Sistema

Verificar consistência

Verificar consistência

Analisar Interdependências

e Resolver conflitos

Não Sim

Incluir

Restrições?

Acabou cenários

Incluir Cenários

sem contudo se preocupar com a funcionalidade (FRANCO&LEITE, 1 9 92)

(LEITE&FRANCO, 1993).

De modo geral o LEL define os seguintes passos a serem realizados:

1) Elicitação de requisitos – separar períodos compostos em orações simples,

transformar orações na voz passiva para voz ativa e formas substantivas de

verbos para formas verbais correspondentes.

2) Identificação dos símbolos – palavras ou frases com significado especial,

procurando por sujeitos, verbos, objetos e estados (predicativos).

3) Classificação dos símbolos identificados

4) Descrição dos símbolos – criar entradas no LEL referentes aos símbolos

identificados.

O modelo de processo do LEL é apresentado na Figura 4.4.

FIGURA 4.4 – MODELO DE PROCESSO DE CONSTRUÇÃO DO LEL NA ABORDAGEM DAORE

Seguindo o processo proposto na construção do LEL na figura 4.4 podemos

observar que:


1. O processo se inicia com a formatação dos requisitos elicitados;

2. É feito a identificação dos símbolos do LEL de acordo com o modelo

proposto por (LEITE, 1997);

3. A inclusão de cenários é feita de forma trivial seguindo orientação de

construção de cenários a partir do LEL da linguagem (LEITE, 1997);

4. A inclusão de restrições3: (RNF e RO) é realizada após a construção de

cenários. Porém, podemos incluir estas restrições durante a sua

construção;

5. Adaptamos a proposta de Cysneiros (2001) incluindo os requisitos não

funcionais (que fazem parte das restrições de qualidade do sistema)

após a inclusão de todos os cenários ou em conjunto com eles;

6. A verificação de consistência é necessária para conseguir buscar uma

otimização dos cenários e restrições geradas . P r e v ê ainda que

possamos minimizar o uso de estratégias de satisfação (tabela 4.3) que

podem trazer conseqüências negativas para o projeto e verificar a

dependência entre RNF gerados.

44..22..33 FFaassee 33 –– DDeeffiinniiççããoo ddee AAssppeeccttooss CCaannddiiddaattooss

Segundo Souza (2004), que se utiliza de casos de uso, o aspecto ou requisito

aspectual possui as seguintes características:

a) representa uma preocupação que deve ser inserida num caso de uso base,

alterando o fluxo de execução desse caso de uso, mas cujo propósito não está diretamente

associado ao objetivo do caso de uso base;

b) pode ser desvinculado do caso de uso base sem que isso impeça a realização

do objetivo do caso de uso;

c) ele é (ou pode vir a ser) aplicado em vários casos de uso e não apenas num

caso de uso específico.

3 Na implementação da ferramenta para validar a abordagem foi incluído restrições OCL na construção de cenários.


Neste trabalho é utilizado a técnica de cenários, logo, a identificação dos

aspectos candidatos deve ser realizada após a inclusão dos cenários no LEL, isto porque

irá facilitar o processo de identificação.

O processo de abstrair símbolos ou especificações que possam representar uma

preocupação que está atravessada no projeto, ou seja, um possível aspecto candidato,

pode ser identificado na abordagem através das seguintes diretrizes:

D1) RNFs – a identificação de requisitos não funcionais é um forte candidato a

ser um aspecto, pois como sabemos os RNFs são transversais por natureza (Yu et al 2004).

Deste modo, todos os RNF serão mapeados como aspectos candidatos.

D2) Um cenário incluído pode ser um aspecto candidato a partir das seguintes

características:

a) não está associado diretamente a um Ator;

b) aparece como uma restrição ou extensão de um cenário principal ou

base (o que possui a funcionalidade principal);

c) é (ou pode vir a ser) aplicado em vários cenários base; e

d) se o retirarmos não altera a funcionalidade do cenário base.

Este aspecto candidato terá alguns campos especiais:

· Tipo de contribuição - Esta contribuição pode ser negativa (quando irá

influenciar negativamente para o entendimento e complexidade do

cenário base) ou positiva (ele contribui de forma a auxiliar na

compreensão do cenário), de acordo com a tabela 4.3.

· Tipo de Composição – Esta composição segue o padrão proposto por

Souza (2004).

4.2.3.1 - Identificando Contribuições dos Aspectos Candidatos

As contribuições dos aspectos candidatos em relação aos cenários devem ser

identificadas, ou seja, o quanto um aspecto irá restringir ou influenciar o cenário. Esta

contribuição poderá definir se existem aspectos que não serão implementados, devido à

alta contribuição negativa em relação ao sistema. Esta decisão é fator exclusivamente de

gerência de projeto e deve ser feita em conjunto com os usuários envolvidos.


De forma geral, quando restringe de forma negativa, deve-se levar em conta

que estamos lidando com usuários e, estes, não gostam de perda de tempo em determinada

tarefa, por exemplo. Assim, se temos um aspecto que demanda em determinado cenário

que este irá demorar um pouco mais para ser satisfeito, devemos tomar cuidados para

avaliar a situação caso a caso.

As contribuições podem ser determinadas através da tabela 4.6.

TABELA 4.6– CONTRIBUIÇÕES DOS ASPECTOS

Aspectos Candidatos Aspecto 1 Aspecto 2 ... Aspecto n Cenário

- + - + - + - +

Cenário 1 X X Cenário 2 X X X ... Cenário N

4.2.3.2 - Definindo a Composição dos Aspectos Candidatos

Em linguagem mais simples a definição de composição é realizada para

identificar como será a chamada para a execução do aspecto. Para isso utilizaremos o

modelo proposto por Souza (2004), com adaptações para cenários.

Devem ser determinadas informações a respeito da composição entre um

requisito aspectual e os cenários afetados por ele e, devem ser definidas num artefato à parte,

conforme verificado na Tabela 4.7.

Esta tabela deve ser especificada para cada requisito aspectual de acordo com o

roteiro apresentado a seguir.

TABELA 4.7 –. COMPOSIÇÃO DOS ASPECTOS IDENTIFICADOS

ASPECTO CANDIDATO: #ID <NOME>

CENARIO

AFETADO

CONDIÇÃO REGRA DE COMPOSIÇÃO PONTO DE

JUNÇÃO

INFORMAÇÕES

ADICIONAIS

#ID <NOME> CONDIÇÃO DA

EXTENSÃO

{overlap.after|

overlap.before|

override.wrap}

PASSO DO

CENÁRIO

INFORMAÇÕES

RELATIVAS A

COMPOSIÇÃO

Para preencher a tabela 4.7 deve ser seguido o seguinte roteiro:


1) Para cada ponto que um requisito aspectual precisar afetar num cenário, haverá

uma entrada na tabela de composição nível 1 cujas colunas devem ser

preenchidas da seguinte maneira:

a . C ENARIO AFETADO: preencha com o nome do cenário no qual o

comportamento do aspecto candidato deve ser inserido.

b. CONDIÇÃO (OPCIONAL): preencha essa coluna caso haja alguma condição

que deve ser satisfeita para que o comportamento do aspecto candidato seja

inserido no cenário.

c. REGRA DE COMPOSIÇÃO: preencha com algum dos seguintes operadores

de composição (MOREIRA et al., 2002): overlap (before ou after), override e

wrap. A escolha entre esses operadores dependerá de como o comportamento do

aspecto candidato deve ser aplicado no ponto de junção (ver descrição dos

operadores no Capítulo 2). A definição de qual operador utilizar deve ser feita

em conjunto com os stakeholders (em conjunto com o engenheiro de requisitos).

d. PONTO DE JUNÇÃO: preencha com o passo do cenário no qual o

comportamento do aspecto candidato deve ser aplicado.

e. INFORMAÇÕES ADICIONAIS (OPCIONAL): preencha com alguma outra

informação que deseje acrescentar sobre a composição do aspecto candidato.

4.2.3.3 - Identificando Conflitos

Como estamos trabalhando com a tabela de composição utilizada por Souza

(2004), a resolução de conflitos segue o mesmo padrão.

Neste caso, os conflitos são identificados quando diferentes aspectos

candidatos devem ser aplicados em um mesmo ponto de junção de um cenário.

Quando temos operadores de composição diferentes, a ordem de execução dos

aspectos deve seguir a ordem de precedência dos seus respectivos operadores de

composição. Entretanto, se dois ou mais aspectos devem ser aplicados num mesmo ponto

de junção de um cenário com o mesmo operador de composição, então existe um conflito,

e a ordem de precedência deve ser decidida pelo analista e definida numa tabela de

conflitos (Tabela 4.8).


Existirá apenas uma tabela de conflitos para todo o sistema, na qual todos os

cenários são listados nas linhas e os requisitos aspectuais nas colunas. Caso exista um

conflito de um requisito aspectual num passo de um cenário, a ordem de precedência desse

aspecto em relação aos aspectos com que ele conflita deve ser especificada na célula de

interseção entre o cenário e o aspecto da seguinte forma: P[numPassoConfl]-

[siglaOperador]=[ordemPreced], onde:

· numPassoConfl deve ser substituído pelo número do passo do cenário onde existe o

conflito;

· siglaOperador deve ser substituído por: (i) “OB”, caso o conflito ocorra com o

operador overlap.before; (ii) “OA”, caso o conflito ocorra com o operador

overlap.after; (iii) “O”, caso o conflito ocorra com o operador override; ou “W”,

caso o conflito ocorra com o operador wrap; e

· ordemPreced deve ser substituído pela ordem de precedência do aspecto candidato.

Vamos supor que, além do aspecto candidato A C#01- Verificação de débito,

um outro aspecto candidato cujo identificador é AC#03 precisasse ser aplicado no passo 3

do cenário CN#05 - Fazer matrícula em disciplina com o operador wrap; e que a

prioridade de execução fosse concedida para o aspecto AC#03. Então, a tabela de conflitos

deveria ser preenchida conforme apresentado na Tabela 4.8.

TABELA 4.8 – EXEMPLO DE PREENCHIMENTO DA TABELA DE CONFLITOS

AC#1 AC#2 AC#3 AC#4 CN#1 CN#2 CN#3 CN#4 CN#5 P3-W =2º P3-W=1º

Á medida que os pontos de junção vão sendo refinados nos fluxos seguintes,

esses conflitos podem deixar de existir. Contudo, essas prioridades definidas na tabela de

conflitos serão úteis não somente caso o conflito persista nos fluxos de análise e projeto,

mas também para auxiliar na definição dos pontos de junção nesses fluxos.


44..22..44 FFaassee 44 –– MMaappeeaammeennttoo ddee OOnnttoolloogg iiaass

Segundo Gruber (2006) ontologias são especificações formais e explicitas de

conceitualizações compartilhadas, ou seja, são modelos conceituais que capturam e

explicitam o vocabulário nas aplicações semânticas.

Breitman (2005) destaca que ontologias servem como base para garantir uma

comunicação livre de ambigüidades.

O consorcio W3C (2006) define uma ontologia como: “a definição dos termos

utilizados na descrição e na representação de uma área do conhecimento. Devem prover

descrições para os seguintes tipos de conceito: classes, relacionamentos e propriedades”.

Inicialmente o processo de mapeamento de ontologias foi proposto por

Breitman & Leite (2003) e incorporado ao processo de construção do léxico existente na

DAORE.

TABELA 4.9 –. MAPEAMENTO DOS ELEMENTOS DO LEL PARA OS ELEMENTOS DA ONTOLOGIA. FONTE: BREITMAN&LEITE (2003).

Elementos do LEL Elementos da Ontologia Objeto e Sujeito Classes Estado Classe ou propriedade Verbo Propriedade Noção Descrição Impacto –verbo Propriedade Impacto – predicado(termos) Classes ou axiomas

No mapeamento descrito na tabela 4.9 podemos observar que os elementos ou

termos classificados como do tipo objeto e sujeito são mapeados em classes da ontologia;

os elementos classificados como do tipo verbo são mapeados para propriedades. Os

termos classificados como do tipo estado para classes ou propriedades, dependendo de

sua importância relativa para a ontologia; a noção de cada termo é mapeada na descrição

da respectiva classe; e através da lista de impactos de cada termo do léxico mapeia-se o

verbo em propriedades e o predicado em restrições (axiomas) das classes.

Breitman (2005) argumenta ainda que este processo de mapeamento é

independente da linguagem de implementação da ontologia, como , por exemplo a OWL4,

entre outras.

4 Disponível em http://www.co-ode.org/resources/tutorials/protegeowltutorial.pdf


Nossa proposta realiza a conversão de acordo com a tabela 4.9. No capítulo 5

veremos na prática como irá funcionar.

O processo de mapeamento de ontologias inclui também a construção da

hierarquia de classes e consiste na análise da ontologia de modo a identificar conceitos que

possam estar relacionados hierarquicamente.

Breitman (2005) argumenta que as classes de uma ontologia se relacionam,

estruturalmente, através do relacionamento de especialização, ou seja, no topo da

ontologia fica o elemento mais genérico, e nas suas folhas os mais específicos.

Para facilitar o entendimento vamos expor o exemplo apresentado por

Breitman (2005), onde apresenta termos referentes a um domínio de sobremesas.

A construção da hierarquia de classes sugerida tem como resultado a tabela

4.10.

TABELA 4.10 –. EXEMPLO DE HIERARQUIA DE CLASSES . FONTE: BREITMAN (2005). Classe Pai Classes relacionadas Torta Torta de coco

Petit-gateau Torta de limão

Pudim Pudim de chocolate Pudim de laranja Manjar de coco

Mousse Mousse de maracujá Mousse de cupuaçu Mousse de limão

A tabela 4.8 apresenta a classe pai criada para conter as classes filho

relacionadas.

44..22..55 GGee rraaççããoo ddee aa rrqquuiivvooss ppaa rraa EExxppoo rrttaaççããoo

Apesar de não estar no modelo de processo proposto (figura 4.1) a exportação

do modelo LEL, ontologias e aspectos através de um documento XML são muito

importantes a fim de permitir uma interoperabilidade entre ferramentas.

O trabalho de Wiese (2006) aborda a questão de interoperabilidade entre as

ferramentas de desenvolvimento, realizando um trabalho de transformação entre modelos

de casos de uso, entre as ferramentas: Poseidon5, Enterprise Architect6 e a Requisite.

5 Disponível para download em: http://www.gentleware.com/.


LELCenario.xsd

LELSimbolos.xsd

Porém, este trabalho não lida com casos de uso, mas sim do LEL, aspectos e

ontologias. Deste modo, a definição de padrões de documentos XML Schema é importante

no sentido de que eles servem para validar arquivos XML e permitirem uma organização

da nomenclatura a ser utilizada.

Os documentos XML Schema foram gerados através da ferramenta Stylus

Studio 6 XML Enterprise Edition7 e são organizados como se segue:

1) Padronizando os termos usados nos símbolos do LEL

2) Padronizando os termos usados nos cenários do LEL;

3) Padronizando os termos usados nos elementos da ontologia;

4) Padronizando os termos com as classes pai e seus filhos da ontologia

5) Padronizando os termos usados nos aspectos candidatos;

Os arquivos XML Schemas propostos estão na íntegra no anexo A.

44..33 CCoonnssiiddee rraaççõõeess ssoobbrree aa aa bboo rrddaaggeemm DDAAOORREE

Serão apresentadas algumas considerações sobre a abordagem DAORE,

proposta neste capítulo, em relação aos objetivos propostos e abordagens estudadas no

capítulo 2.

44..33..11 CCoo mm RRee llaaççããoo aaooss OObbjjeett iivvooss PPrroo ppoossttooss

A tabela 4.11 apresenta as considerações da abordagem DAORE com relação

aos objetivos propostos.

6 Disponível para download em: http://www.sparxsystems.com/ 7 Esta ferramenta se encontra disponível para download em: www.stylusstudio.com/.

ontologia.xsd

ontohierarquia.xsd

AspectosLEL.xsd


A coluna Objetivo Proposto apresenta o que se deseja, a coluna abordagem

DAORE apresenta como foi realizada na abordagem e a coluna considerações apresenta

observações julgadas pertinentes.

TABELA 4.11 – DAORE E OS OBJETIVOS PROPOSTOS

Objetivo Proposto Abordagem DAORE Considerações Utilizar o LEL e permitir a identificação de propriedades transversais do projeto

Através de diretrizes para este fim.

As propriedades transversais são obtidos após a especificação dos cenários.

Suporte a metodologia MDSODI na definição dos cenários e das propriedades transversais

Através da definição do tipo do cenário especificado.

Para o ator envolvido no cenário, seu tipo será definido de acordo com o mesmo.

Permitir um alto grau de usabilidade

Permite uma rápida compreensão e entendimento do método, uma vez que utiliza de conceitos já existentes (LEL)

A forma de elaboração do LEL não foi alterada. Apenas acrescentou-se novas características (restrições)

Boa adequação quanto à identificação de propriedades transversais

A identificação de propriedades transversais é feita de forma semi-automática

Através das diretrizes propostas

Identificar requisitos organizacionais, através de suas operacionalizações

Através da inclusão de restrições nos cenários.

Especificar XML Schemas para auxiliar na exportação de documentos padrão no formato XML

Foi criado XML Schemas para este fim

Utilizou-se de símbolos do LEL, cenários, aspectos e ontologias, tanto dos termos quanto da hierarquia de classes.

Facilitar a resolução de conflitos

Através de padrão existente definido por Souza (2004)

Pode ser gerado automaticamente.

Facilitar o rastreamento de requisitos

Através do principio do LEL de circularidade e vocabulário mínimo.

Este princípio não foi alterado.

44..33..22 UUssoo nnaa RReeqquuiissiittee ee nnoo PPrroo jjeettoo DDiiSSEENN

No capítulo 6 será apresentado em detalhes as mudanças a realizadas (e as que

podem ser realizadas) na ferramenta Requisite a fim de prover as características

determinadas na DAORE, bem como no projeto DiSEN.


44..33..33 DDiiffee rreennççaass ccoomm aass AAbboo rrddaaggeennss EEssttuuddaaddaass

Por definir os cenários através do LEL, a abordagem DAORE já é única em sua

concepção, uma vez que não foi encontrada uma abordagem que se utiliza do LEL e

aspectos. Por outro lado, a DAORE conseguiu buscar algumas características das

abordagens estudadas que facilitam o seu entendimento (como pode ser verificado na

tabela 4.1).

A abordagem DAORE em seu objetivo básico “facilitar a identificação das

propriedades transversais” consegue minimizar o problema de identificação comum na

maioria das abordagens.

Assim, seu diferencial principal está em aliar a praticidade e a maturidade do

LEL nos projetos com a identificação das propriedades transversais a partir deste LEL.

Aliado a isso, podemos incluir o tipo de cenário utilizado a partir da metodologia

MDSODI, o que a torna integrada a metodologia.


Neste capítulo foram apresentadas as diretrizes para a abordagem DAORE, o

que ela propõe e suas fases para o desenvolvimento na fase de requisitos.

As regras definidas pela abordagem perfazem um conjunto de conceitos

integrados das abordagens estudadas no Capítulo 3 com algumas adaptações e inserções

novas (como a utilização de padrões de qualidade para a definição dos requisitos não

funcionais e a identificação e integração dos requisitos organizacionais na modelagem).

Outro aspecto importante da DAORE é o de permitir a portabilidade e

interoperabilidade entre plataformas e ferramentas, através do padrão XML, de acordo

com o XML Schema elaborado para este fim, desde o LEL proposto para o projeto até os

elementos da ontologia dos projetos, sem esquecer dos aspectos candidatos.

Neste capítulo procuramos dar uma atenção especial na elicitação dos

requisitos e como identificar os aspectos (uma preocupação constante em todas as

abordagens estudadas) utilizando nossa abordagem, de forma semi-automática.

Assim, procuramos minimizar um dos principais problemas existentes na

separação de propriedades: a sua efetiva identificação.


No próximo capítulo faremos a experimentação da abordagem e será realizado

uma análise do impacto das mudanças a serem efetuadas na ferramenta Requisite,

apresentadas no capítulo 6.

5.Experimentação: Controle de Eventos Científicos 113

CAPÍTULO

55

EXPERIMENTAÇÃO: CONTROLE DE EVENTOS

CIENTÍFICOS

As palavras que não são seguidas de fatos não servem para nada. Demóstenes

SSeegguunnddoo TTRRAAVVAASSSSOOSS eett aa ll ((22000022)) eexxiiss tteemm dduuaass ttééccnniiccaass ppaarraa

aavvaalliiaarr uummaa aabboorrddaaggeemm:: eexxppeerr iimmeennttooss ee eess ttuuddooss ddee ccaassoo.. AA

rreeaa lliizzaaççããoo ddee eexxppeerr iimmeennttooss pprroovvêê uummaa mmaanneeiirraa ddee aavvaalliiaaççããoo

bbaasseeaaddaa eemm ccoommppaarraaççããoo ddiirreettaa,, ppeerrmmiitt iinnddoo aaooss ppeessqquuiissaaddoorreess

iinnvveess tt iiggaarr qquuaall oo iimmppaacc ttoo ddaa tteeccnnoollooggiiaa nnoo pprroocceessssoo ddee mmaanneeiirraa

ddeettaallhhaaddaa.. OO eess ttuuddoo ddee ccaassooss eess ttáá pprreeooccuuppaaddoo eemm aavvaalliiaarr ooss

bbeenneeffíícc iiooss ddee uummaa aabboorrddaaggeemm ppaarraa vveerr iiff iiccaarr ssee aass mmuuddaannççaass nnoo

pprroocceessssoo pprrooppoorrcc iioonnaarraamm oo rreessuullttaaddoo eessppeerraaddoo..

AA ttééccnniiccaa eessccoollhhiiddaa ppaarraa eess ttee tt rraabbaallhhoo ffooii oo ddee eexxppeerr iimmeennttaaççããoo..

AApplliiccaarreemmooss aa aabboorrddaaggeemm DDAAOORREE eemm uumm ss iiss tteemmaa ddee ssooffttwwaarree

ffiicc ttíí cc iioo ddee uummaa eemmpprreessaa qquuee rreeaa lliizzaa eevveennttooss cc iieennttíí ffiiccooss ,, oo mmeessmmoo

aapprreesseennttaaddoo ppoorr BBaattiiss ttaa ((22000033)),, ppoorréémm ccoomm oo aaccrréésscc iimmoo ddee oouuttrraass

ccaarraacc tteerríí ss ttiiccaass..

IInniicc iiaa llmmeennttee aapprreesseennttaarreemmooss oo ss iiss tteemmaa pprrooppooss ttoo,, sseeuuss rreeqquuiiss iittooss

ffuunncciioonnaaiiss ,, nnããoo ffuunncc iioonnaaiiss ee oorrggaanniizzaacc iioonnaaiiss .. AA ppaarrttiirr ddeess ttaa bbaasseelliinnee


ddeesseennvvoollvveerreemmooss nnoossssoo pprroojjeettoo aa ff iimm ddee ccoommppaarraarrmmooss ccoomm oo

aanntteerr iioorr ((rreeaa lliizzaaddoo nnoo ccaappiittuulloo 66))..

55..11 OObbjjeett iivvooss

Este estudo de caso tem o propósito de: (i) mostrar como a DAORE pode ser

usada para melhorar o entendimento e identificação dos crosscutting concerns em um

processo de engenharia de requisitos; e (ii) avaliar se a DAORE contribuirá para

reusabilidade, manutenibilidade e compreensibilidade dos crosscutting concerns sobre os

projetos desenvolvidos utilizando a MDSODI.

Este estudo de caso é o mesmo elaborado para a validação da ferramenta

Requisite, escolhemos o mesmo para facilitar o processo de comparação e análise do

impacto do uso da abordagem DAORE para o processo de desenvolvimento.

A seguir descreveremos o contexto do sistema proposto para realizar nossa

avaliação final.

55..22 AA EEssccoollhhaa ddaa FFeerrrraa mmeennttaa ddee IImmpplleemmeennttaaççããoo

A escolha da ferramenta OORNF para apoiar a abordagem proposta se deve a

algumas considerações:

a) A ferramenta Requisite estava sendo analisada e alterada por Wiese (2006) para

seu projeto, de modo que somente após o término deste trabalho poderia ser analisado o

quanto foi alterada, pois inicialmente nem mesmo possuía persistência em seus dados e

identificação de seus termos (elementos do LEL);

b) Foram feitas algumas análises de outras ferramentas existentes que utilizassem o

LEL da linguagem, como a OORNF1 e a C&L2, onde foi constatado:

b.1) A ferramenta OORNF possui persistência, identificação dos símbolos

do LEL e possui integrado os requisitos não funcionais na definição do LEL, fo i

desenvolvida em Delphi.

1 (CYSNEIROS, 2002) desenvolvida no trabalho do prof. Cysneiros da Universidade de York, Toronto-Canadá, que disponibilizou o código fonte. 2 Disponível no site http://139.82.24.189/cel/, onde possui inclusive o código fonte.


b.2) A ferramenta C&L possui persistência, identificação dos símbolos do

LEL e possui integrado a construção de ontologias do LEL, foi desenvolvida em PHP.

c) O objetivo principal da DAORE é o de facilitar a identificação de aspectos

candidatos, onde podemos primeiramente salientar os derivados dos requisitos não

funcionais.

Baseado, principalmente no item C, foi escolhida a ferramenta OORNF para a

alteração, por já ter integrado os requisitos não funcionais, mesmo que fosse feita alteração

na forma da integração, pois facilitaria a identificação dos aspectos candidatos.

A nova versão da OORNF passou a chamar-se CALEL – Candidates Aspects from

LEL, aprovado pelo prof. Cysneiros. Alterada no sentido de prover recursos para a

inclusão de ontologias, requisitos organizacionais e a exportação nos padrões

especificados no Capítulo 4, suas telas estão no anexo B.

Porém, a alteração prevista da ferramenta Requisite está descrita em detalhes no

Capítulo 6. O uso da CALEL foi apenas para fins de estudo de caso.

55..33 OO SSiisstteemmaa PP rrooppoossttoo

Uma empresa presta serviços de gerenciamento de eventos.

O cliente ou também chamado de cliente em potencial pode consultar os

eventos que estão com para acontecer e os eventos que já ocorreram. Caso goste de algum

evento poderá solicitar seu cadastro como cliente cadastrado, assim, poderá fazer sua

inscrição para os eventos que irão ocorrer. Seu cadastro será analisado e caso seja

aprovado (depende de consulta do CPF e órgãos compententes), poderá inscrever-se como

ouvinte, para assistir as palestras, apresentações e cursos do evento ou poderá enviar

trabalhos (short paper, long paper ou pôster), sendo a aceitação do trabalho condicionada à

avaliação por comitê cientifico. Em qualquer dos dois casos (ouvinte ou participante)

deverá pagar a inscrição.

Os clientes cadastrados também podem participar do evento como palestrante

ou ministrante. O palestrante é convidado pela comissão organizadora para realizar uma

ou mais palestras durante o evento. O ministrante é convidado pela comissão organizadora

para ministrar um ou mais cursos durante o evento. Nestes casos o participante estará

isento da taxa de inscrição.


O participante deverá enviar os slides nos prazos estabelecidos para tal, bem

como o ministrante deverá enviar o material do curso a ser ministrado, bem como a

requisição de recursos necessários para a sua execução nos prazos estabelecidos.

A comissão organizadora elaborará a programação do evento com base nos

trabalhos, cursos e palestras. A comissão também é responsável por cadastrar os parceiros

do evento (fornecedores, patrocinadores).

Os recursos financeiros são providos pelos patrocinadores e irão servir para

pagar os fornecedores do evento (de recursos materiais e humanos). A secretaria é

responsável por distribuir os recursos financeiros recebidos.

Mesmo os clientes já cadastrados devem se preocupar em verificar sua situação

junto aos órgãos competentes quando da sua inscrição para um novo evento. Caso sua

situação não esteja em ordem sua inscrição deverá ocorrer apenas se o pagamento for em

débito em conta.

Não serão convidados (palestrantes e ministrantes) pessoas com problemas

com os órgãos competentes.

Crachás de identificação devem ser entregues a todos os participantes do

evento. Só será permitido o acesso ao evento aos portadores de crachás.

Para comprovar a participação no evento, os participantes receberão

certificados de participação. Os certificados só deverão ser emitidos para os participantes

com, no mínimo 85% de presença.

A empresa deseja conseguir o maior número de clientes VIP. Um cliente VIP é

aquele que solicita mais de três eventos anuais. A este cliente é concedido um desconto

especial de 30% nos serviços prestados. Para os participantes que são freqüentes (mais de

três eventos anuais) também é oferecido descontos especiais em hotéis, restaurantes e

outros patrocinadores, possuindo um cartão de Cliente VIP da empresa.

55..44 FFaassee 11 -- IIddeennttiiff iiccaannddoo ooss RRee qquuiissiittooss

Seguindo o modelo proposto por Toranzo (2002) e já colocando os requisitos

de acordo com as regras estabelecidas para o LEL, construímos a tabela 5.1 e 5.2.


TABELA 5.1 – REQUISITOS DO SISTEMA

RReeqquuiiss iittooss ffuunncc iioonnaaiiss

SSeeccrreettáárr iiaa ccaaddaa ssttrraa cc lliieennttee PPaarrtt iicc iippaannttee ccoonnss uullttaa eevveennttoo ss ee mm aabbee rrttoo PPaarrtt iicc iippaannttee ccoonnss uullttaa eevveennttoo ss ffeecchhaaddoo ss SSeeccrreettáárr iiaa ccoonnss uullttaa eevveennttooss ee mm aabbeerr ttoo SSeeccrreettáárr iiaa ccaaddaa ssttrraa oouuvviinnttee ee mm uumm eevveennttoo ee mm aabbeerr ttoo OOuuvviinntt ee ssee ccaaddaass ttrraa ee mm uumm eevveennttoo ee mm aabbeerr ttoo PPaarrtt iicc iippaannttee ssee ccaaddaass ttrraa ee mm uumm eevveennttoo ee mm aabbeerrttoo PPaarrtt iicc iippaannttee eennvviiaa ttrraabbaa llhhooss SSeeccrreettáárr iiaa oouu aa ccoo mmiiss ssããoo aa llttee rraa oo pp aarrtt iicc iippaannttee ee mm uumm eevveennttoo ee mm aabbee rrttoo ccoo mm nnoo mmíínnii mmoo 2244 hhoorraa ss ddee aanntteecceeddêênncc iiaa

SSeeccrreettáárr iiaa oouu oo ccoo mmiitt êê eexxcc lluuee mm oo ppaarr tt iicc iippaannttee ee mm uumm eevveennttoo ee mm aabbeerr ttoo ccoo mm nnoo mmíínniimmoo 77 ddiiaass úúttee iiss ddee aanntteecceeddêênncc iiaa SSeeccrreettáárr iiaa ccoonnss uullttaa ppaa rrtt iicc iippaanntteess ee mm uumm eevveennttoo SSeeccrreettáárr iiaa ccaaddaa ssttrraa eevveennttoo SSeeccrreettáárr iiaa ccaaddaa ssttrraa ccoo mmiissssããoo oorr ggaanniizzaaddoorr aa ddoo eevveennttoo SSeeccrreettáárr iiaa ccaaddaa ssttrraa ccoo mmiittêê cc iieenntt ííffiiccoo ddoo eevveennttoo CCoommiittêê cc iieenntt ííffiiccoo ssee lleecc iioonnaa ttrraabbaa llhhooss CCoommiissssããoo oorr ggaanniizzaaddoo rraa ccaaddaass ttrraa pprrooggrraa mmaaççããoo ddoo eevveennttoo CCoommiissssããoo ccoonnffeecccc iioonnaa ccrraacchhááss ddoo eevveennttoo PPaarrtt iicc iippaannttee rreecceebbee cc rraacchháá CCoommiissssããoo ee llaabboorraa cceerr tt iiffiiccaaddooss ddee ppaarr tt iicc iippaaççããoo ppaa rraa ooss pp aarrtt iicc iippaanntteess ccoo mm,, nnoo mmíínn iimmoo,, 8855%% ddee pprreesseennççaa CCoommiissssããoo ccaaddaa ssttrr aa mmiinniiss ttrraanntt ee CCoommiissssããoo ccaaddaa ssttrr aa ppaa lleess ttrraannttee MM iinniiss ttrraannttee aapprree sseennttaa ccuurrssooss aapprreesseennttaaddoo rr aapprree sseennttaa ttrraabbaa llhhooss PPaalleesstt rraannttee aapp rreesseennttaa ppaa llee ssttrraa PPaarrtt iicc iippaannttee rreecceebbee ccee rrtt iiffiiccaaddooss ddee ppaarr tt iicc iippaaççããoo CCoommiissssããoo ccaaddaa ssttrr aa ppaattrroo cc iinnaaddoorr eess ddoo eevveennttoo OOuuvviinntt ee ee//oouu aapp rreesseenntt aaddoorr ee ffee tt uuaa ppaaggaa mmeennttoo ddoo eevveennttoo

TABELA 5.2 – REQUISITOS NÃO FUNCIONAIS E ORGANIZACIONAIS DO SISTEMA

RReeqquuiiss iittooss nnããoo ff uunncc iioonnaaiiss AAcceessssoo llooccaa ll SSeegguurraannççaa AAcceessssoo iinnttee rr nneett

AAttrraavvééss ddee sseennhhaa ee ffiirr eewwaa llll

RReeqquuiiss iittooss oorrggaannii zzaacciioonnaa iiss GGeerreenncc iiaarr cc lliieenntteess VVIIPP FFaaccii llii ttaa rr oo aaccee ssss oo ddee eevveennttooss aa cclliieennttee ss

VVII PP EEmmiitt iirr ccaarr ttããoo pprree ffeerreenncc iiaa ll OO ppaarrtt iicc iipp aannttee aaoo ss ee ccaaddaass ttrraarr ee mm uumm eevveennttoo oo ss iissttee mmaa vveerr áá ssee ee llee éé uumm cc lliieennttee VVIIPP oouu ssee ttee mm ppoott eenncc iiaa ll ppaarraa ss eerr uumm cc lliieennttee VVIIPP PPaarraa ooss nnoovvooss cc lliieenntt eess VVIIPP sseerráá ee mmiitt iiddoo uumm ccaarr ttããoo pprree ffeerreenncc iiaa ll

Nem sempre observamos os requisitos não funcionais e muitas vezes eles não

estão explícitos. A tabela 4.3 apresentada no Capitulo 4 pode servir de base para que


possamos incluir os requisitos não funcionais de uma forma mais natural, uma vez que

grande parte dos requisitos não funcionais já estão listados.

Veremos mais adiante que nossos requisitos não funcionais e organizacionais

serão incluídos de maneira distintas dos requisitos funcionais.

No Anexo E demonstramos a inclusão do Léxico através da ferramenta

CALEL, cuja Figura 5.1 demonstra a tela:

FIGURA 5.1 – MENU PRINCIPAL DA FERRAMENTA CALEL.

55..44 FFaassee 22 -- CCoonnssttrruuiinnddoo oo llééxxiiccoo

Para a construção do léxico iremos, primeiramente incluir os requisitos

funcionais do sistema. A Figura 5.2 apresenta a tela de inclusão do léxico.


FIGURA 5.2 – TELA DE INCLUSÃO DO LEL

Para a construção do léxico, primeiramente incluímos os requisitos funcionais

do sistema. A Figura 5.2 apresenta a tela de inclusão do léxico.

Os símbolos apresentados na Tabela 5.3 foram identificados nos requisitos

funcionais para a inclusão no LEL.

TABELA 5.3 – SÍMBOLOS DO LEL ENCONTRADOS NOS REQUISITOS FUNCIONAIS

tipo Descrição Sujeito Secretária/Auxiliar, Participante, ouvinte, ministrante, palestrante,

apresentador, fornecedor/patrocinador/parceiro, c o m i s s ã o organizadora/comissão, comitê científico/comitê, cliente inscrito/cliente cadastrado, cliente/cliente em potencial

Estado Em aberto/aberto/abertos, fechado/fechados Objeto Evento, trabalhos/trabalho, programação/programa, crachá/crachás,

certificado/certificados/certificado de participação, pagamento, recursos/recurso, material de aula, slides/palestra, inscrição

Verbo Incluir cliente/cadastrar cliente/cliente cadastrado, consultar eventos em aberto, consultar eventos fechados, alterar participante, excluir participante, consultar participante, cadastrar comissão, cadastrar comitê, receber recursos, distribuir recursos, pagar fornecedor, efetuar inscrição, efetuar pagamento, enviar material, enviar requisição, enviar trabalho, enviar palestra, fornecer recursos, receber pagamento, s elecionar ministrante, selecionar palestrante, emitir crachás, emitir certificados, elaborar programação, cadastrar parceiros, solicitar inscrição


A tabela 5.4 possui em detalhes as entradas do LEL correspondente aos

símbolos encontrados na tabela 5.3, vale observar que o termo sublinhado indica que faz

parte do próprio léxico.

TABELA 5.4 – SÍMBOLOS DO LEL DETALHADO

RReeqquuiiss iittooss ffuunncc iioonnaaiiss

SSíí mmbboolloo SSeeccrreettaarr iiaa// AAuuxxiilliiaa rr CCaatteeggoorriiaa SSuujjee iittoo NNooççããoo PPeessssooaa qquuee aauuxxiilliiaa nnoo ggee rreenncc iiaa mmeennttoo ddoo eevveennttoo II mmppaa ccttoo AAççõõeess qquuee eexxeeccuuttaa ::

11.. ccaaddaassttrraa rr cc lliieennttee,, 22.. ccoonnss uullttaa rr eevveennttoo ss ee mm aabbee rrttoo 33.. ccoonnss uullttaa rr eevveennttoo ss ffeecchhaaddooss 44.. aa lltteerr aarr ppaarr tt iicc iippaannttee 55.. eexxcc lluuiirr pp aarrtt iicc iippaannttee 66.. ccoonnss uullttaa rr ppaarr tt iicc iippaanntteess 77.. ccaaddaassttrraa rr eevveennttoo 88.. ccaaddaassttrraa rr ccoo mmiissssããoo 99.. ccaaddaassttrraa rr ccoo mmiittêê 1100.. rreecceebbeerr rr eeccuurrssooss 1111.. ppaaggaa rr ffoorr nneecceeddoorr 1122.. ddiissttrr iibbuuiirr rreeccuurrssooss 1133.. rreecceebbeerr ppaaggaa mmeennttoo

SSíí mmbboolloo PPaarrtt iicc iippaannttee CCaatteeggoorriiaa SSuujjee iittoo NNooççããoo PPeessssooaa qquuee ppaarr tt iicc iippaa ddee uumm eevveennttoo ccoo mmoo :: oouuvviinnttee,, aapprr eesseennttaaddoo rr,, ppaa llee ssttrr aannttee,,

mmiinniiss ttrraannttee II mmppaa ccttoo AAççõõeess qquuee eexxeeccuuttaa ::

11.. ccoonnss uullttaa rr eevveennttoo ss ee mm aabbee rrttoo 22.. ccoonnss uullttaa rr eevveennttoo ss ffeecchhaaddooss 33.. ccoonnss uullttaa rr pprrooggrraa mmaaççããoo

SSíí mmbboolloo oouuvviinnttee CCaatteeggoorriiaa SSuujjee iittoo NNooççããoo Cliente inscrito para assistir aos cursos, palestras e apresentações do evento II mmppaa ccttoo AAççõõeess qquuee eexxeeccuuttaa ::

11.. eeffeett uuaarr pp aaggaa mmeennttoo

SSíí mmbboolloo CClliieennttee iinnssccrr iittoo //cc lliieennttee ccaaddaasstt rraaddoo CCaatteeggoorriiaa SSuujjee iittoo NNooççããoo PPeessssooaa qquuee ssoo lliicc iittoouu oo ccaaddaass ttrroo ee ffoo ii aapp rroovvaaddaa,, rreecceebbeennddoo oo sseeuu llooggiinn ee sseennhhaa II mmppaa ccttoo AAççõõeess qquuee eexxeeccuuttaa ::

11.. iinnssccrreevvee-- ssee ee mm eevveennttooss 22.. ccoonnss uullttaa rr eevveennttoo ss aabbeerr ttooss 33.. ccoonnss uullttaa rr eevveennttoo ss ffeecchhaaddooss 44.. ccoonnss uullttaa rr pprrooggrraa mmaaççããoo 55.. eennvviiaarr tt rraabbaa llhhoo ss 66.. eeffeett uuaarr pp aaggaa mmeennttoo

SSíí mmbboolloo PPaalleesstt rraannttee CCaatteeggoorriiaa SSuujjee iittoo

NNooççããoo Cliente inscrito para ministrar palestra II mmppaa ccttoo AAççõõeess qquuee eexxeeccuuttaa ::


11.. eennvviiaarr ppaa lleesstt rraa

SSíí mmbboolloo MM iinniiss ttrraannttee CCaatteeggoorriiaa SSuujjee iittoo

NNooççããoo Cliente inscrito para ministrar curso II mmppaa ccttoo AAççõõeess qquuee eexxeeccuuttaa ::

11.. eennvviiaarr mmaatteerr iiaa ll 22.. eennvviiaarr rreeqquuiiss iiççããoo

SSíí mmbboolloo AApprreesseennttaaddoorr CCaatteeggoorriiaa SSuujjee iittoo

NNooççããoo Cliente inscrito para apresentar trabalho II mmppaa ccttoo AAççõõeess qquuee eexxeeccuuttaa ::

11.. eennvviiaarr tt rraabbaa llhhoo

SSíí mmbboolloo CCoommiissssããoo //ccoo mmiissssããoo oo rr ggaanniizzaaddoo rraa CCaatteeggoorriiaa SSuujjee iittoo NNooççããoo GGrr uuppoo ddee ppeess ssooaass ssee lleecc iioonnaadd aass ppaarraa ggee rreenncc iiaarr oo eevveennttoo.. II mmppaa ccttoo AAççõõeess qquuee eexxeeccuuttaa ::

11.. SSeelleecc iioonnaa rr mmiinniiss ttrraanntt ee,, 22.. SSeelleecc iioonnaa rr ppaa lleess ttrraannttee,, 33.. EEmmiitt iirr ccrraacchhááss,, 44.. EEmmiitt iirr cceerr tt iiffiiccaaddoo ss 55.. CCoonnss uullttaarr ppaa rrtt iicc iippaanntteess 66.. EEllaabboo rraarr pprrooggrraa mmaaççããoo 77.. CCaaddaassttrraarr ppaa rrccee iirrooss

SSíí mmbboolloo CCoommiittêê //ccoo mmiittêê cc iieenntt ííffiiccoo CCaatteeggoorriiaa SSuujjee iittoo NNooççããoo GGrr uuppoo ddee ppeessssooaass ssee lleecc iioonnaaddaa ss ppaarraa ssee lleecc iioonnaa rr ooss ttrraabbaa llhhooss aapp rreesseennttaaddooss nnoo

eevveennttoo.. II mmppaa ccttoo AAççõõeess qquuee eexxeeccuuttaa ::

11.. SSeelleecc iioonnaa rr ttrraabb aa llhhooss 22.. AAlltt eerraarr ppaa rrtt iicc iippaannttee

SSíí mmbboolloo PPaarrccee iirroo ss//PPaarrccee iirroo //FFoorr nneecceeddoo rr//PPaa ttrroocc iinnaaddoorr CCaatteeggoorriiaa SSuujjee iittoo NNooççããoo EEmmpp rreessaass qquuee ffoorr nneeccee mm rreeccuurrssooss (( mmaatt eerr iiaa iiss,, ffiinnaannccee iirrooss oouu hhuummaannooss)) pp aarraa aa

rreeaa lliizzaaççããoo ddoo eevveennttoo II mmppaa ccttoo AAççõõeess qquuee eexxeeccuuttaa ::

11.. FFoorrnneecceerr rreeccuurrssooss 22.. ccoonnss uullttaa rr eevveennttoo ss 33.. ccoonnss uullttaa rr pprrooggrraa mmaaççããoo

SSíí mmbboolloo FFoorrnneecceeddoorr CCaatteeggoorriiaa SSuujjee iittoo NNooççããoo EEmmpp rreessaass qquuee ffoo rr nneeccee mm rreeccuurrssooss mmaattee rr iiaa iiss ee//oouu hhuummaannoo ss ppaarraa aa rreeaa lliizzaaççããoo ddoo

eevveennttoo II mmppaa ccttoo AAççõõeess qquuee eexxeeccuuttaa ::

11.. rreecceebbeerr ppaaggaa mmeennttoo__ rreeccuurrssoo

SSíí mmbboolloo EEvveennttoo //eevveennttoo ss CCaatteeggoorriiaa OObbjjeettoo NNooççããoo CCoonnffeerr eenncc iiaa oouu WWoorrkk ss hhoopp aa sseerr ggeerr eenncc iiaaddoo ppee llaa ee mmpp rreessaa.. CCaaddaa eevveennttoo ppooss ss uuii

uumm pp eerr ííooddoo ddee rreeaa lliizzaaççããoo.. ÉÉ ccoo mmppoo ssttoo ddee uummaa oouu mmaa iiss ppaa lleesstt rraass,, ccuurr ssooss ee tt rraabbaa llhhoo ss

II mmppaa ccttoo 11.. CClliieennttee iinnssccrr iittoo ppooddee iinnssccrr eevveerr-- ssee ee mm eevveennttoo 22.. OO eevveennttoo ee ssttáá aabbee rrttoo oouu ffeecchhaaddoo

SSíí mmbboolloo TTrraabbaa llhhooss// ttrraabbaa llhhoo CCaatteeggoorriiaa OObbjjeettoo

NNooççããoo AArrtt iiggooss aa ssee rree mm aapp rreesseennttaaddooss ee mm uumm eevveennttoo


PPooddee sseerr :: ss hhoo rrtt ppaappee rr,, ffuullll ppaappeerr ee ppoossttee rr II mmppaa ccttoo 11.. AApprreesseennttaaddoorr eennvviiaa uumm oouu mmaa iiss ttrraabb aa llhhooss

22.. OO ttrraabbaa llhhoo ppooddee ssee rr ssee lleecc iioonnaaddoo ppaa rraa ssee rr aapprreesseennttaaddoo ppoorr uumm ccoo mmiittêê

SSíí mmbboolloo PPrrooggrraa mmaaççããoo //pprrooggrraa mmaa CCaatteeggoorriiaa OObbjjeettoo

NNooççããoo CCrroonnooggrraa mmaa aa ssee rr ccuummpp rr iiddoo ddoo eevveennttoo CCoonnttee mm aass ppaa lleesstt rraass,, tt rraabbaa llhhoo ss ee ccuurrssoo ss aa sseerr ee mm aapprr eesseennttaaddooss nnoo eevveennttoo

II mmppaa ccttoo 11.. CCoommiissssããoo ee llaabboorraa pp rrooggrraa mmaaççããoo pprreevviissttaa ddoo eevveennttoo 22.. AA pprrooggrraa mmaaççããoo ppooddee ss eerr aa lltteerraadd aa ccaassoo ooccoorr rraa aa llgguumm iimmpprreevviissttoo

SSíí mmbboolloo CCeerrtt iiffiiccaaddoo// cceerrtt iiff iiccaaddoo ppaarr tt iicc iippaaççããoo CCaatteeggoorriiaa OObbjjeettoo NNooççããoo CCoommpprroovvaannttee ddee ppaa rrtt iicc iippaaççããoo ddoo eevveennttoo II mmppaa ccttoo 11.. CCoommiissssããoo ee llaabboorraa ccee rrtt iiffiiccaaddooss ppaarraa oo ss ppaarr tt iicc iippaanntteess

22.. CCeerrtt iiffiiccaaddooss ss eerrããoo eennttrreegguueess nnoo uulltt iimmoo dd iiaa ddoo eevveennttoo oouu vviiaa ccoorr rree iioo

SSíí mmbboolloo CCrraacchháá ss//ccrr aacchháá CCaatteeggoorriiaa OObbjjeettoo NNooççããoo IIddeenntt iiffiiccaaççããoo ddoo ppaarrtt iicc iipp aannttee ddoo eevveennttoo II mmppaa ccttoo 11.. CCoommiissssããoo ee mmiitt ee ccrraacchháá ss ppaarraa ooss pp aarrtt iicc iippaanntteess

22.. CCrraacchháá ss sseerrããoo eennttrreegguuee ss nnoo pprr iimmee iirroo dd iiaa ddoo eevveennttoo 33.. CCrraacchháá ss ssããoo rreecceebb iiddooss ppee llooss ppaarr tt iicc iippaanntt eess

SSíí mmbboolloo PPaaggaa mmeennttoo CCaatteeggoorriiaa OObbjjeettoo

NNooççããoo Comprovante de quitação com o evento II mmppaa ccttoo 11.. OOuuvviinnttee//ppaa lleess ttrraanntt ee eenntt rreeggaa ccoopp iiaa ddoo ppaaggaa mmeennttoo ee ffeett uuaaddoo vviiaa ee-- mmaa iill,,

ccoorrrree iioo,, oouu nnoo pp rr iimmee iirroo dd iiaa ddoo eevveennttoo

SSíí mmbboolloo RReeccuurrssoo ss//rr eeccuurrssoo CCaatteeggoorriiaa OObbjjeettoo NNooççããoo São materiais necessários para a realização e elaboração do evento.

Podem ser: financeiro, humano e material II mmppaa ccttoo OOss rreeccuurrssoo ss ffiinnaannccee iirrooss ssããoo dd iissppoonniibb iill iizzaaddooss aanntteess ddooss rreeccuurrssoo ss mmaatteerr iiaa iiss ee

hhuummaannooss

SSíí mmbboolloo MMaatteerr iiaa ll// mmaa tteerr iiaa iiss CCaatteeggoorriiaa OObbjjeettoo

NNooççããoo OO mmaa tteerr iiaa ll rree ffeerreennttee aaoo ccuurr ssoo aa sseerr mmiinn iisstt rraaddoo ee mm uumm eevveennttoo II mmppaa ccttoo 11.. MM iinniiss ttrraannttee eennvviiaa uumm oouu mmaa iiss mmaattee rr iiaa iiss

22.. OO mmaa tteerr iiaa ll ppooddee ssee rr ssee lleecc iioonnaaddoo ppoo rr uumm ccoo mmiitt êê

SSíí mmbboolloo PPaalleesstt rraa CCaatteeggoorriiaa OObbjjeettoo

NNooççããoo Slides referentes a um assunto a ser apresentado no evento II mmppaa ccttoo 11.. PPaalleesstt rraannttee eennvviiaa uummaa oouu mmaa iiss ppaa llee ssttrraa ss

22.. AA ppaa lleess ttrraa ppooddee sseerr ssee lleecc iioonnaaddaa ppoorr uumm ccoo mmiittêê

SSíí mmbboolloo RReeqquuiiss iiççããoo CCaatteeggoorriiaa OObbjjeettoo NNooççããoo Documento que contem referencias aos recursos materiais necessários para

realizar a tarefa II mmppaa ccttoo 11.. MM iinniiss ttrraannttee eennvviiaa aappeennaass uummaa rreeqquuiiss iiççããoo

SSíí mmbboolloo CCaaddaassttrraarr cc lliieennttee CCaatteeggoorriiaa VVeerrbboo NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llaa ss eeccrree ttáárr iiaa

AAccoonntteeccee qquuaannddoo :: aa ppeess ssooaa ssoo lliicc iittaa sseeuu ccaaddaasstt rroo ccoo mmoo cc lliieennttee iinnssccrr iittoo PPrréé-- ccoonndd ::

11.. PPeessssooaa iinntt eerreessss aaddaa eennvviiaa sseeuuss ddaaddooss ccaadd aasstt rraa iiss 22.. SSeeccrreettáárr iiaa rreecceebbee ooss ddaaddooss ee rreeaa lliizzaa aannáá lliiss ee..

IInnffoorr mmaaççõõeess ssããoo aapp rroovvaaddaass II mmppaa ccttoo 11.. CClliieennttee ee ssttáá ccaaddaa ssttrr aaddoo

22.. SSee oo cc lliieennttee eesstt áá ccaaddaass ttrraaddoo aa sseeccrreett áárr iiaa nnããoo ppooddee ccaaddaass ttrráá-- lloo..


PPóóss-- ccoonndd :: 11.. SSeeccrreettáárr iiaa eennvviiaa llooggiinn ee sseennhhaa ppaa rraa oo cc lliieennttee iinnssccrr iittoo..

SSíí mmbboolloo CCoonnss uullttaarr eevveennttoo ss ee mm aabbee rrttoo // eevveennttooss ee mm aabbeerrttoo ssããoo ccoonnss uullttaaddooss

CCaatteeggoorriiaa VVeerrbboo

NNooççããoo AAççããoo rreeaa lliizzaaddaa ppee llaa sseecc rreettáá rr iiaa,, ppaarr tt iicc iippaannttee,, ppaarrccee iirrooss,, cc lliieenntteess ccaaddaasstt rraaddooss,, cc lliieenntteess AAccoonntteeccee qquuaannddoo :: aa ppeessssoo aa//ee mmpprreessaa ddeessee jjaa ssaabbeerr qquuaa iiss ooss eevveennttooss eessttããoo aa aaccoonntteecceerr

II mmppaa ccttoo 11.. EEvveennttoo ss ffoorraa mm ccoonnss uullttaaddooss.. PPóóss-- ccoonndd ::

SSíí mmbboolloo CCoonnss uullttaarr eevveennttooss ffeecchhaaddooss// eevveennttooss ffeecchhaaddooss ssããoo ccoonnss uulltt aaddooss


NNooççããoo AAççããoo rreeaa lliizzaaddaa ppee llaa sseecc rreettáá rr iiaa,, ppaarr tt iicc iippaannttee,, ppaarrccee iirrooss,, cc lliieenntteess ccaaddaasstt rraaddooss,, cc lliieenntteess AAccoonntteeccee qquuaannddoo :: aa ppeessssooaa //ee mmpp rreessaa dd eesseejjaa ssaabbee rr qquuaa iiss ooss eevveennttooss aaccoonntteecceerraa mm

II mmppaa ccttoo 11.. EEvveennttoo ss ffoorraa mm ccoonnss uullttaaddooss..

SSíí mmbboolloo AAlltt eerraarr ppaa rrtt iicc iippaannttee// ppaa rrtt iicc iippaannttee aa lltteerraaddoo CCaatteeggoorriiaa VVeerrbboo NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llaa ss eeccrree ttáárr iiaa,, ccoo mmiittêê

AAccoonntteeccee qquuaannddoo :: oo ppaarr tt iicc iippaanntt ee ddee oouuvviinnttee ppaassssaa aa sseerr uumm aapprreesseennttaaddoorr PPrréé-- ccoonndd ::

11.. PPaarrtt iicc iippaannttee eessttáá ccaaddaasstt rraaddoo nnoo eevveennttoo ccoo mmoo oouuvviinnttee 22.. CCoommiittêê ssee lleecc iioonnaa ttrr aabbaa llhhoo ddoo oouuvviinnttee

II mmppaa ccttoo 11.. ppaarrtt iicc iippaanntt ee eessttáá aa lltt eerraaddoo..

SSíí mmbboolloo EExxcc lluuiirr ppaa rrtt iicc iippaannttee//ppaa rrtt iicc iippaannttee eexxcc lluuiiddoo CCaatteeggoorriiaa VVeerrbboo

NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llaa ss eeccrree ttáárr iiaa AAccoonntteeccee qquuaannddoo :: oo ppaarr tt iicc iippaanntt ee nnããoo ppooddee eess ttaarr nnoo eevveennttoo PPrréé-- ccoonndd :: 11.. PPaarrtt iicc iippaannttee iinnffoo rr mmaa aa ss eeccrree ttáárr iiaa ss uuaa pprroovváávvee ll aauussêênncc iiaa

II mmppaa ccttoo 11.. PPaarrtt iicc iippaannttee eessttáá eexxcc lluuííddoo.. PPóóss-- ccoonndd ::

11.. SSee oo ppaarrtt iicc iippaanntt ee ffoorr uumm oouuvviinnttee oouu aapprreess eennttaaddoorr ee oo pprraazzoo ddaa eexxcc lluussããoo ffoo rr mmaa iioorr qquuee 55 dd iiaass úúttee iiss,, oo vvaa lloorr ddeevvoo llvviiddoo ssee rráá ddee 8800%%

22.. CCoomm eexxcceeççããoo ddoo ppaarr tt iicc iippaannttee ss eerr uumm oouuvviinnttee,, sseerráá eennvviiaaddoo ee-- mmaa iill ppaarraa ooss oouuvviinntteess ssoobbrree aa aa llttee rraaççããoo ee ffeett uuaaddaa..

SSíí mmbboolloo CCoonnss uullttaarr ppaarr tt iicc iippaanntteess // ppaa rrtt iicc iippaannttee ccoonnss uullttaaddoo


NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llaa ss eeccrree ttáárr iiaa,, ccoo mmiissssããoo AAccoonntteeccee qquuaannddoo :: ddeessee jjaa-- ssee ccoonnhheeccee rr ooss ppaarrtt iicc iipp aanntteess ddee uumm eevveennttoo ee mm aabbee rrttoo oouu ffeecchhaaddoo

II mmppaa ccttoo 11.. PPaarrtt iicc iippaannttee ss ffoorraa mm ccoonnss uullttaaddooss .. PPóóss-- ccoonndd ::

SSíí mmbboolloo CCaaddaassttrraarr eevveennttoo// eevveennttoo ccaaddaa ssttrr aaddoo CCaatteeggoorriiaa VVeerrbboo NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llaa ss eeccrree ttáárr iiaa

AAccoonntteeccee qquuaannddoo :: aa ee mmpprreessaa rreecceebbee uumm eevveennttoo ppaa rraa ggeerreenncc iiaarr II mmppaa ccttoo 11.. EEvveennttoo ee ssttáá ccaadd aasstt rraaddoo..

SSíí mmbboolloo CCaaddaassttrraarr ccoo mmiiss ssããoo//ccoo mmiiss ssããoo ccaaddaass ttrraaddaa CCaatteeggoorriiaa VVeerrbboo

NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llaa ss eeccrree ttáárr iiaa AAccoonntteeccee qquuaannddoo :: oo eevveennttoo nnããoo ppoossss uuii ccoo mmiissssããoo


II mmppaa ccttoo 11.. CCoommiissssããoo eess ttáá ccaaddaa ssttrraadd aa..

SSíí mmbboolloo CCaaddaassttrraarr ccoo mmiitt êê//ccoo mmiitt êê ccaaddaass ttrraaddoo CCaatteeggoorriiaa VVeerrbboo

NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llaa ss eeccrree ttáárr iiaa AAccoonntteeccee qquuaannddoo :: oo eevveennttoo nnããoo ppoossss uuii ccoo mmiittêê oo rr ggaanniizzaaddoo rr

II mmppaa ccttoo 11.. CCoommiittêê eess ttáá ccaaddaa ssttrraaddoo.. PPóóss-- ccoonndd ::

SSíí mmbboolloo RReecceebbeerr rreeccuurr ssooss// rreeccuurrssoo ss rreecceebb iiddooss CCaatteeggoorriiaa VVeerrbboo NNooççããoo AAççããoo ssoo ffrr iiddaa ppee llaa sseecc rreettáá rr iiaa

AAccoonntteeccee qquuaannddoo :: oo eevveennttoo nnããoo ppoossss uuii rreeccuurrssooss PPrréé-- ccoonndd :: 11.. PPaarrccee iirroo ss ffoorr nneeccee mm rreeccuurrssooss

II mmppaa ccttoo 11.. RReeccuurrssoo ss ffoorraa mm rreecceebb iiddooss.. PPóóss-- ccoonndd ::

SSíí mmbboolloo DDiiss ttrr iibbuuiirr rreeccuurrssoo ss//rreeccuurrssooss dd iiss ttrr iibbuuiiddooss CCaatteeggoorriiaa VVeerrbboo

NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llaa ss eeccrree ttáárr iiaa AAccoonntteeccee qquuaannddoo :: oo eevveennttoo nnããoo ppoossss uuii rreeccuurrssooss PPrréé-- ccoonndd ::

11.. RReeccuurrssoo ss ffoorraa mm rreecceebb iiddooss 22.. EEvveennttoo ppoo ssss uuiirr nneecceessss iiddaaddee ddee rr eeccuurrssooss

II mmppaa ccttoo 11.. RReeccuurrssoo ss ffoorraa mm rreecceebb iiddooss..

SSíí mmbboolloo PPaaggaarr ffoorr nneecceeddoo rr// ffoorr nneecceeddoo rreess ppaaggooss CCaatteeggoorriiaa VVeerrbboo NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llaa ss eeccrree ttáárr iiaa

AAccoonntteeccee qquuaannddoo :: oo eevveennttoo ppoossss uuii rreeccuurr ssooss ppaarraa ppaaggaa mmeennttoo ddee ffoo rr nneecceeddoorr PPrréé-- ccoonndd ::

11.. ffoo rr nneecceeddoorr ffoorr nneecceeuu rreeccuurrssoo ss 22.. ffoo rr nneecceeddoorr nnããoo ffoo ii ppaaggoo

II mmppaa ccttoo 11.. FFoorrnneecceeddoorr ffoo ii ppaaggoo.. PPóóss-- ccoonndd :: 11.. FFoorrnneecceeddoorr rreecceebbee ppaaggaa mmeennttoo__rreeccuurrssoo

SSíí mmbboolloo RReecceebbeerr pp aaggaa mmeennttoo//ppaaggaa mmeennttoo rreecceebb iiddoo CCaatteeggoorriiaa VVeerrbboo NNooççããoo AAççããoo ssoo ffrr iiddaa ppee llaa sseecc rreettáá rr iiaa

AAccoonntteeccee qquuaannddoo :: aa sseeccrree ttáárr iiaa rreecceebbeeuu oo ppaaggaa mmeennttoo ddoo oouuvviinnttee ee//oouu aapprreesseennttaaddoo rr PPrréé-- ccoonndd ::

11.. OOuuvviinntt ee ee//oouu aapp rreesseenntt aaddoorr eess ttããoo iinnss ccrr iittooss nnoo eevveennttoo 22.. OOuuvviinntt ee ee//oouu aapp rreesseenntt aaddoorr ee ffee tt uuoouu ppaaggaa mmeennttoo

II mmppaa ccttoo 11.. PPaaggaa mmeennttoo ffoo ii rreecceebb iiddoo..

SSíí mmbboolloo CCoonnss uullttaarr pprrooggrr aa mmaaççããoo // pprrooggrraa mmaaççããoo ccoonnss uullttaaddaa


NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llooss ppaa rrtt iicc iippaanntteess,, ppaa rrccee iirrooss,, cc lliieennttee ss iinnsscc rr iittooss,, cc lliieenntt eess AAccoonntteeccee qquuaannddoo :: ddeessee jjaa-- ssee ccoonnhheecceerr aa pprrooggrraa mmaaççããoo ddee uumm eevveennttoo PPrréé-- ccoonndd ::

11.. EEvveennttoo ss ee mm aabbee rrttoo ssããoo ccoonnss uullttaaddooss 22.. EEvveennttoo éé ssee lleecc iioonnaaddoo

II mmppaa ccttoo 11.. PPrrooggrraa mmaaççããoo ccoonnss uullttaaddaa..

SSíí mmbboolloo IInnssccrreevvee rr-- ssee ee mm eevveennttoo // iinnssccrr iiççããoo ee ffee tt uuaaddaa CCaatteeggoorriiaa VVeerrbboo NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee lloo cc lliieennttee iinnss ccrr iittoo

AAccoonntteeccee qquuaannddoo :: ddeessee jjaa-- ssee iinnsscc rreevveerr-- ssee ppaarr aa uumm eevveennttoo ee mm aabbee rrttoo PPrréé-- ccoonndd ::


33.. EEvveennttoo ss ee mm aabbee rrttoo ssããoo ccoonnss uullttaaddooss 44.. EEvveennttoo éé ssee lleecc iioonnaaddoo

II mmppaa ccttoo 11.. IInnssccrr iiççããoo éé ee ffee tt uuaaddaa..

SSíí mmbboolloo EEnnvviiaa rr ttrr aabbaa llhhoo //ttrraabb aa llhhoo eennvviiaaddoo CCaatteeggoorriiaa VVeerrbboo

NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee lloo aapp rreesseenntt aaddoorr AAccoonntteeccee qquuaannddoo :: oo cc lliieennttee iinnss ccrr iittoo ddeesseejj aa eennvviiaarr uumm ttrraabbaa llhhoo ppaarraa aapprreesseennttaaççããoo PPrréé-- ccoonndd ::

11.. CClliieennttee iinnssccrr iittoo eessttáá ccaaddaass ttrraaddoo nnoo eevveennttoo ee mm aabbeerr ttoo ccoo mmoo aapprreesseennttaaddoo rr

PPrraazzoo dd ee ss uubb mmiissssããoo ddee ttrraabbaa llhhooss eess ttáá vvaa lleennddoo II mmppaa ccttoo 11.. ttrraabbaa llhhoo éé eennvviiaaddoo..

PPóóss-- ccoonndd ::

SSíí mmbboolloo EEffee tt uuaarr ppaaggaa mmeennttoo // ppaaggaa mmeennttoo ee ffeett uuaaddoo CCaatteeggoorriiaa VVeerrbboo NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee lloo oouuvviinnttee ee //oouu aapprreess eennttaaddoorr

AAccoonntteeccee qquuaannddoo :: oo oouuvviinnttee ee //oouu aapprree sseennttaaddoo rr ppoossss uuii ppaaggaa mmeennttoo aa ffaazzeerr ddoo eevveennttoo PPrréé-- ccoonndd ::

11.. oouuvviinnttee ee //oouu aapprreesseennttaaddoorr ee ssttããoo iinnssccrr iittoo ss nnoo eevveennttoo II mmppaa ccttoo 11.. ppaaggaa mmeennttoo éé ee ffeett uuaaddoo..

PPóóss-- ccoonndd :: 11.. PPaaggaa mmeennttoo éé rreecceebb iiddoo ppee llaa sseecc rreettaa rr iiaa

SSíí mmbboolloo EEnnvviiaa rr ppaa llee ssttrraa // ppaa lleesstt rraa eennvviiaaddaa CCaatteeggoorriiaa VVeerrbboo

NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee lloo ppaa lleesstt rraannttee AAccoonntteeccee qquuaannddoo :: oo ppaa lleesstt rraannttee ddee sseejjaa eennvviiaarr aa pp aa lleess ttrraa ppaa rraa oo eevveennttoo PPrréé-- ccoonndd ::

11.. CClliieennttee iinnssccrr iittoo ee ssttáá ccaaddaa ssttrr aaddoo nnoo eevveennttoo ee mm aabbeerr ttoo ccoo mmoo pp aa lleess ttrraannttee 22.. PPrraazzoo dd ee eennvviioo ddaass pp aa lleess ttrraass eessttáá vvaa lleennddoo

II mmppaa ccttoo 11.. ppaa lleesstt rraa éé eennvviiaaddaa.. PPóóss-- ccoonndd ::

SSíí mmbboolloo EEnnvviiaa rr mmaa tteerr iiaa ll// mmaa tteerr iiaa ll eennvviiaaddoo CCaatteeggoorriiaa VVeerrbboo NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee lloo mmiinniiss ttrr aannttee

AAccoonntteeccee qquuaannddoo :: oo mmiinniiss ttrraannttee ddeessee jjaa eennvviiaa rr oo mmaa tteerr iiaa ll ddoo ccuurr ssoo ppaarraa oo eevveennttoo PPrréé-- ccoonndd ::

11.. CClliieennttee iinnssccrr iittoo ee ssttáá ccaaddaa ssttrr aaddoo nnoo eevveennttoo ee mm aabbeerr ttoo ccoo mmoo mmiinn iisstt rraannttee 22.. PPrraazzoo dd ee eennvviioo ddoo mmaattee rr iiaa ll eessttáá vvaa lleennddoo

II mmppaa ccttoo 11.. mmaatteerr iiaa ll éé eennvviiaaddoo..

SSíí mmbboolloo EEnnvviiaa rr rreeqquuiiss iiççããoo // rreeqquuiiss iiççããoo eennvviiaaddaa CCaatteeggoorriiaa VVeerrbboo NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee lloo mmiinniiss ttrr aannttee

AAccoonntteeccee qquuaannddoo :: oo mmiinniiss ttrraannttee ddeessee jjaa eennvviiaarr aa rreeqquuiiss iiççããoo ddoo mmaatteerr iiaa ll ddoo ccuurr ssoo ppaarraa oo eevveennttoo PPrréé-- ccoonndd ::

11.. CClliieennttee iinnssccrr iittoo ee ssttáá ccaaddaa ssttrr aaddoo nnoo eevveennttoo ee mm aabbeerr ttoo ccoo mmoo mmiinn iisstt rraannttee 22.. PPrraazzoo dd ee eennvviioo ddoo mmaattee rr iiaa ll eessttáá vvaa lleennddoo

II mmppaa ccttoo 11.. rreeqquuiiss iiççããoo éé eennvviiaaddaa..

SSíí mmbboolloo SSeelleecc iioonnaa rr mmiinniiss ttrraannttee// mmiinniiss ttrraannttee ssee lleecc iioonnaaddoo


NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee lloo ccoo mmiiss ssããoo


AAccoonntteeccee qquuaannddoo :: oo ccoo mmiissssããoo ddee sseejjaa ss ee lleecc iioonnaarr oo(( ss)) mmiinniiss ttrraannttee((ee )) ppaarraa oo eevveennttoo PPrréé-- ccoonndd ::

EEvveennttoo ppoo ssss uuii vvaaggaa ss nnooss hhoorráá rr iiooss dd ee pprrooggrraa mmaaççããoo II mmppaa ccttoo 11.. mmiinniiss ttrraannttee éé ssee lleecc iioonnaaddoo..

PPóóss-- ccoonndd :: 11.. ÉÉ eennvviiaaddoo ee-- mmaa iill ppaa rraa oo mmiinniiss ttrraannttee ccoo mm oo ccoonnvviittee ddoo eevveennttoo ccoonntteennddoo :: aassss uunnttoo ddee iinntteerr eessssee ddoo ccuurrssoo,, pprraazzoo ee sstt iimmaaddoo ppaa rraa oo eennvviioo ddoo mmaattee rr iiaa ll ee rreeqquuiiss iiççããoo ee iinnffoorr mmaaççõõeess ggeerr aa iiss ssoobb rree oo eevveennttoo..

SSíí mmbboolloo SSeelleecc iioonnaa rr ppaa llee ssttrraannttee// ppaa lleess ttrraannttee ssee lleecc iioonnaaddoo


NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee lloo ccoo mmiiss ssããoo AAccoonntteeccee qquuaannddoo :: oo ccoo mmiissssããoo ddeesseejj aa ssee lleecc iioonnaa rr oo((ss )) ppaa lleesstt rraannttee ((ee)) ppaa rraa oo eevveennttoo PPrréé-- ccoonndd ::

11.. EEvveennttoo ppoo ssss uuii vvaaggaa ss nnooss hhoorráá rr iiooss dd ee pprrooggrraa mmaaççããoo II mmppaa ccttoo 11.. ppaa lleesstt rraannttee éé ssee lleecc iioonnaaddoo..

PPóóss-- ccoonndd :: 11.. ÉÉ eennvviiaaddoo ee-- mmaa iill ppaa rraa oo ppaa lleesstt rraannttee ccoo mm oo ccoonnvviittee ddoo eevveennttoo ccoonntteennddoo :: aassss uunnttoo ddee iinntteerr eessssee ddaa ppaa lleess ttrraa,, pprraazzoo eesstt iimmaaddoo ppaa rraa oo eennvviioo ddooss ss lliiddeess ee iinnffoorr mmaaççõõeess ggee rraa iiss ssoobbrree oo eevveennttoo..

SSíí mmbboolloo EEmmiitt iirr ccrraacchhááss// cc rraacchhááss ee mmiitt iiddooss CCaatteeggoorriiaa VVeerrbboo

NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llaa ccoo mmiiss ssããoo AAccoonntteeccee qquuaannddoo :: ffaa llttaa mm tt rrêêss dd iiaass ppaarraa oo iinniicc iioo ddoo eevveennttoo

II mmppaa ccttoo 11.. ccrraacchhááss ffoo rraa mm ee mmiitt iiddooss.. PPóóss-- ccoonndd :: 11.. ccrraacchhááss ssããoo rreecceebb iiddoo ss ppee llooss pp aarrtt iicc iippaanntteess

SSíí mmbboolloo EEmmiitt iirr cceerr tt iiffiiccaaddoo ss// ccee rrtt iiffiiccaaddoo ss ee mmiitt iiddooss CCaatteeggoorriiaa VVeerrbboo

NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llaa ccoo mmiiss ssããoo AAccoonntteeccee qquuaannddoo :: ffaa llttaa uumm dd iiaa pp aarraa oo tt eerr mmiinnoo ddoo eevveennttoo

II mmppaa ccttoo 11.. cceerrtt iiffiiccaaddoo ss ffoorraa mm ee mmiitt iiddooss..

SSíí mmbboolloo EEllaabboo rraarr pp rrooggrraa mmaaççããoo// pp rrooggrraa mmaaççããoo ee llaabboorraaddaa //aatt uuaa lliizzaa rr pprrooggrraa mmaaççããoo//pprrooggrraa mmaaççããoo aatt uuaa lliizzaaddaa


NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llaa ccoo mmiiss ssããoo AAccoonntteeccee qquuaannddoo aa ccoo mmiissssããoo ppooss ss uuii ppaa llee ssttrraannttee(( ss)) ee//oouu mmiinniiss ttrraannttee ee//oouu aapprreesseennttaaddoo rr aa ssee rr iinncc lluuííddoo nnaa pprrooggrraa mmaaççããoo PPrréé-- ccoonndd ::

II mmppaa ccttoo 11.. pprrooggrraa mmaaççããoo ffoo ii aa tt uuaa lliizzaaddaa..

SSíí mmbboolloo CCaaddaassttrraarr ppaa rrccee iirrooss// pp aarrccee iirrooss ccaaddaa ssttrr aaddooss CCaatteeggoorriiaa VVeerrbboo

NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llaa ccoo mmiiss ssããoo AAccoonntteeccee qquuaannddoo aa ccoo mmiissssããoo ppoo ssss uuii ppaa rrccee iirrooss aa ssee rree mm iinncc lluuííddooss ppaa rraa uumm eevveennttoo PPrréé-- ccoonndd :: 11.. OO eevveennttoo ee ssttáá aabbee rrttoo

II mmppaa ccttoo 11.. ppaarrccee iirroo ffoo ii ccaadd aasstt rraaddoo..

SSíí mmbboolloo SSeelleecc iioonnaa rr ttrraabb aa llhhoo// ttrraabbaa llhhoo ssee lleecc iioonnaaddoo CCaatteeggoorriiaa VVeerrbboo NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee lloo ccoo mmiitt êê

AAccoonntteeccee qquuaannddoo aa ccoo mmiittêê ppoossss uuii tt rraabbaa llhhooss aa ssee rree mm ssee lleecc iioonnaaddooss ppaarraa uumm


eevveennttoo PPrréé-- ccoonndd ::

EEvveennttoo ppoo ssss uuii vvaaggaa ss nnooss hhoorráá rr iiooss dd ee pprrooggrraa mmaaççããoo II mmppaa ccttoo 11.. ttrraabbaa llhhoo ffoo ii ss ee lleecc iioonnaaddoo..

SSíí mmbboolloo FFoorrnneecceerr rreeccuurrssooss // rreeccuurrssooss ffoo rr nneecc iiddoo ss CCaatteeggoorriiaa VVeerrbboo NNooççããoo AAççããoo rreeaa lliizzaadd aa ppee llooss ppaa rrccee iirrooss

AAccoonntteeccee qquuaannddoo oo ppaarrccee iirroo ppoossss uuii rreeccuurrssooss ppaa rraa oo eevveennttoo PPrréé-- ccoonndd ::

11.. ppaarrccee iirroo eessttáá ccaaddaasstt rraaddoo ppaarraa oo eevveennttoo eevveennttoo eesstt áá ee mm aabbee rrttoo

II mmppaa ccttoo 11.. rreeccuurrssooss ffoorraa mm ffoorr nneecc iiddooss..

SSíí mmbboolloo RReecceebbeerr pp aaggaa mmeennttoo__rreeccuurrssoo// ppaaggaa mmeennttoo__ rreeccuurrssoo rreecceebb iiddoo


NNooççããoo AAççããoo ssoo ffrr iiddaa ppee llooss ppaarr ccee iirroo ss AAccoonntteeccee qquuaannddoo oo ppaarrccee iirroo tt ee mm ccrr eedd iittoo aa rreecceebbee rr PPrréé-- ccoonndd ::

sseeccrreettáá rr iiaa ee ffeett uuaa pp aaggaa mmeennttoo aaoo ffoorr nneecceeddoorr II mmppaa ccttoo 11.. ppaaggaa mmeennttoo__ rreeccuurrssoo ffoo ii rr eecceebb iiddoo..

PPóóss-- ccoonndd ::

SSíí mmbboolloo CClliieennttee // cc lliieennttee ee mm ppootteenncc iiaa ll CCaatteeggoorriiaa SSuujjee iittoo NNooççããoo PPeessssooaa qquuee aa iinnddaa nnããoo ssoo lliicc iittoouu oo ccaaddaass ttrroo,, aappeennaa ss cc lliieennttee ee mm ppootteenncc iiaa ll II mmppaa ccttoo AAççõõeess qquuee eexxeeccuuttaa ::

11.. ccoonnss uullttaa rr eevveennttoo ss aabbeerr ttooss 22.. ccoonnss uullttaa rr eevveennttoo ss ffeecchhaaddooss 33.. ccoonnss uullttaa rr pprrooggrraa mmaaççããoo 44.. ssoo lliicc iittaa iinnssccrr iiççããoo

SSíí mmbboolloo iinnssccrr iiççããoo CCaatteeggoorriiaa OObbjjeettoo NNooççããoo IIddeenntt iiffiiccaaççããoo ddee uumm cc lliieennttee qquuaannddoo ddeessee jjaa ffaazzeerr sseeuu ccaadd aasstt rroo II mmppaa ccttoo 11.. aa iinnssccrr iiççããoo éé ssoo lliicc iittaaddaa ppee lloo cc lliieenntt ee aa iinnddaa nnããoo iinnssccrr iittoo

SSíí mmbboolloo SSoolliicc iittaarr iinnssccrr iiccaaoo// iinnsscc rr iiççããoo ssoo lliicc iittaadd aa CCaatteeggoorriiaa VVeerrbboo NNooççããoo AAççããoo eexxeeccuuttaaddaa ppee lloo ss cc lliieennttee

AAccoonntteeccee qquuaannddoo oo cc lliieennttee ttee mm iinnttee rreessssee ee mm ssee ccaaddaa ssttrr aarr ee mm uumm ccuurr ssoo II mmppaa ccttoo 11.. iinnssccrr iiççããoo ffoo ii ssoo lliicc iittaaddaa..

::

SSíí mmbboolloo AAbbeerrttoo //ee mm aabbeerrttoo //aabbeerr ttooss //ee mm aabbee rrttooss CCaatteeggoorriiaa EEsstt aaddoo

NNooççããoo SSããoo eevveennttooss qquuee eess ttããoo aaccoonntteecceennddoo oouu ppoorr aaccoonntteeccee rr II mmppaa ccttoo SSee aapp lliiccaa aaoo ss eevveennttooss ccoo mm ppeerr ííooddoo ddee rreeaa lliizzaaççããoo mmaa iioorr oouu iigguuaa ll aa ddaa ttaa aa tt uuaa ll

SSíí mmbboolloo FFeecchhaaddooss // ffeecchhaaddoo CCaatteeggoorriiaa eessttaaddoo

NNooççããoo SSããoo eevveennttooss qquuee aaccoonntteecceerraa mm II mmppaa ccttoo SSee aapp lliiccaa aaoo ss eevveennttooss ccoo mm ppeerr ííooddoo ddee rreeaa lliizzaaççããoo mmeennoo rr ddoo qquuee aa ddaa ttaa aatt uuaa ll

Vale salientar que os termos ou símbolos do LEL foram incluídos observando-

se o principio do vocabulário mínimo e de circularidade.

Pode-se verificar também que algumas restrições existentes nos requisitos

funcionais não foram incluídas (restrições de tempo – mínimo de 24 horas de


antecedência, sete dias de antecedência, entre outros) - . Estas restrições serão incluídas à

parte, como uma restrição OCL a ser incluída no LEL correspondente. Este tipo de

informação torna-se útil na confecção do diagrama, fazendo uma referência explícita de

restrições a serem incluídas.

A seguir foram incluídos os requisitos não funcionais de acordo com a tabela

5.5.

TABELA 5.5 – INCLUSÃO DOS REQUISITOS NÃO FUNCIONAIS

RReeqquuiiss iittooss nnããoo ff uunncc iioonnaaiiss RReeqquuiiss iittoo ff uunncciioonnaa ll pprrii mmáá rriioo

RReeqquuiiss iittoo eess ppeeccííffiiccoo

EEss ttrraa ttééggiiaa ddee ss aattiiss ffaaççããoo

SSíí mmbboolloo ddoo LLEELL aaffee ttaaddoo

Identificação TTooddaass aass aaççõõee ss SSeegguurraannççaa ccoonnffiiddeenncc iiaabb iilliiddaaddee aauutteenntt iiccaaççããoo PPaa rraa ttooddooss ooss

aacceess ss ooss Identificação TTooddaass aass aaççõõeess ddee

aattuuaa llii zzaaççããoo SSeegguurraannççaa iinntteeggrr iiddaaddee

aauutteenntt iiccaaççããoo PPaa rraa ttooddooss ooss aacceess ss ooss ddee aattuuaa llii zzaaççããoo

Observando a tabela 4.3 do capítulo 4, pode-se verificar que vários requisitos

não funcionais, apesar de não explicitados no contexto, poderiam ser aplicados ao projeto,

como: integridade, disponibilidade, usabilidade, entre outros. Porém, para exemplificação,

foi utilizado apenas o requisito não funcional que diz respeito à autorização de acesso e

autenticação (para acesso e atualização dos dados).

A seguir é apresentado os requisitos organizacionais a serem incluídos no LEL

através da tabela 5.6.

TABELA 5.6 – INCLUSÃO DOS REQUISITOS ORGANIZACIONAIS

RReeqquuiiss iittooss oorrggaannii zzaacciioonnaa iiss RReeqquuiiss iittoo oorrggaannii zzaacciioonnaall

EEss ttrraa ttééggiiaa ddee ss aattiiss ffaaççããoo SSíí mmbboolloo ddoo LLEELL aaffee ttaaddoo

Verificar potencial IInnss ccrriiççããoo eevveennttoo IInnss ccrriiççããoo eevveennttoo Validar situação

EEffee ttuuaa rr PPaaggaa mmee nnttoo AApp lliiccaarr ddeessccoonnttoo EEffee ttuuaa rr ppaaggaa mmee nnttoo

CClliieenntteess VVIIPP

EEmmiitt iirr ccaarr ttããoo-- CClliieenntt ee VVIIPP IInnss ccrriiççããoo eevveennttoo


55..55..11 AAnnaalliissaannddoo iinntteerrddeeppeennddêênncciiaass ee rreessoollvveennddoo ccoonnfflliittooss

No nosso projeto, por termos poucos Requisitos não funcionais a serem

satisfeitos e poucos requisitos organizacionais foi mais simples.

Para cada requisito não funcional foi observado se a estratégia de satisfação era

suficiente para operacionalizar o RNF e se ela contribuía positivamente ou negativamente

para isso. Esta informação é muito útil quando temos um sistema maior que envolve várias

autenticações diferentes ou dupla confirmação, por exemplo. Apesar de ser uma influencia

negativa sob o ponto de vista do usuário, deve ser levado em conta o desejo do cliente e a

integridade do sistema como um todo.

Da mesma forma o requisito organizacional foi observado em termos de

satisfação e influência nos o utros termos do LEL. No nosso caso, não houve influencia

negativa, pois as checagens requisitadas são mais simples.

55..55..22 CCoonnssttrruuiinnddoo ooss cceennáárriiooss

Para a construção de cenários foi seguido o padrão estabelecido por HADAD

(1997), onde pode ser verificado com mais detalhes no anexo C. Porém, de forma geral

apresenta como diretrizes principais o mapeamento da tabela 5.7.

TABELA 5.7 – MAPEAMENTO ENTRE OS TERMOS DO LEL

Termos do LEL Cenários verbo Cenário candidato sujeito Ator objeto Recurso

Assim, ao final do processo os cenários apresentados na tabela 5.8, são

elaborados com a incorporação dos requisitos não funcionais – em azul, e organizacionais

– em verde e restrições OCL – em rosa.

Em todos os impactos existentes devem ser tratados os requisitos não

funcionais. De acordo com as regras definidas por Cysneiros (2002) este tratamento é

verificado a cada passo existente nos episódios. Porém, para facilitar o entendimento e a

leitura, foi aplicada a restrição uma única vez. Porém, caso seja necessário, deve ser

colocado a restrição extra no passo que a requer (como pode ser observado em alguns

exemplos).


TABELA 5.8 – CENÁRIOS DO LEL

Título CCoonnss uullttaarr eevveennttooss ee mm aabbeerr ttoo Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee ccoonnhheecceerr ttooddoo ss ooss eevveennttooss qquuee eess ttããoo ee mm aabbeerrttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ccoonnss uullttaa ddee eevveennttooss ee mm aabbeerr ttoo

SSeeccrreettáárr iiaa TTiippoo AAttoorr

PPrr iimmáá rr iioo

PPaarrtt iicc iippaannttee TTiippoo AAttoorr


PPaarrccee iirroo ss TTiippoo AAttoorr

SSeeccuunnddáá rr iioo

CClliieenntteess iinncc lluuiiddooss TTiippoo AAttoorr


Atores

CClliieenntteess TTiippoo AAttoorr


Recursos eevveennttoo Episódios 11.. SSiissttee mmaa eexxiibbee eevveennttooss ee mm aabbeerr ttoo

22.. EEvveennttoo ss ee mm aabbee rrttoo ssããoo ccoonnss uullttaaddooss.. Título CCoonnss uullttaarr eevveennttooss ffeecchhaaddooss Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee ccoonnhheecceerr ttooddoo ss ooss eevveennttooss qquuee jj áá ooccoorrrree rraa mm Contexto SSiissttee mmaa ee mmiitt iinnddoo ccoonnss uullttaa ddee eevveennttooss ffeecchhaaddooss



PPaarrtt iicc iippaannttee TTiippoo AAttoorr


PPaarrccee iirroo ss TTiippoo AAttoorr


CClliieenntteess iinncc lluuiiddooss TTiippoo AAttoorr


Atores

CClliieenntteess TTiippoo AAttoorr


Recursos eevveennttoo Episódios 11.. SSiissttee mmaa eexxiibbee eevveennttooss ffeecchhaaddooss

22.. EEvveennttoo ss ffeecchhaaddooss ssããoo ccoonnss uullttaaddooss.. Título AAlltt eerraarr ppaa rrtt iicc iippaannttee Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee aa llttee rraarr oo tt iippoo ddee ppaa rrtt iicc iippaannttee Contexto SSiissttee mmaa ee mmiitt iinnddoo aa lltteerraaççããoo ddee pp aarrtt iicc iippaannttee ddoo eevveennttoo


PPrr iimmáá rr iioo Atores

CCoommiittêê TTiippoo AAttoorr


Recursos EEvveennttoo Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. SSeeccrreettáárr iiaa// ccoo mmiittêê iidd eenntt iiffiiccaa oo pp aarrtt iicc iippaannttee.. 22.. sseeccrreettáá rr iiaa //ccoo mmiittêê ssee lleecc iioonnaa oo eevveennttoo nnoo qquuaa ll oo ppaa rrtt iicc iippaannttee ddeevvee ssee rr aa lltteerraaddoo.. 33.. sseeccrree ttáárr iiaa//ccoo mmiitt êê aa llttee rraa oo ppaarrtt iicc iipp aannttee.. RRee ssttrr iiççããoo :: DDeevvee tt eerr iinntteeggrr iiddaaddee,, sseennddoo aa eessttrraa ttééggiiaa ddee ssaatt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. RReess ttrr iiççããoo :: mmiinn ddee 2244 hhoorraa ss ddee aanntteecceeddêênncc iiaa ddaa ddaattaa iinniicc iioo ddoo eevveennttoo 44.. ppaarrtt iicc iippaanntt ee éé aa lltteerraaddoo..


Título EExxcc lluuiirr ppaa rrtt iicc iippaannttee Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee eexxcc lluuiirr oo ppaarr tt iicc iippaannttee ddee uumm eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo eexxcc lluuss ããoo ddee ppaarr tt iicc iippaannttee nnoo eevveennttoo

PPrréé ccoonndd :: PPaarr tt iicc iippaannttee iinnffoorr mmaa ppoorr ee-- mmaa iill ss uuaa aauussêênncc iiaa Atores SSeeccrreettáárr iiaa TTiippoo

AAttoorr PPrr iimmáá rr iioo

Recursos EEvveennttoo Episódios .. RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iill iiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. SSeeccrreettáárr iiaa iidd eenntt iiffiiccaa oo pp aarrtt iicc iippaannttee 22.. sseeccrreettáá rr iiaa ssee lleecc iioonnaa oo eevveennttoo ee mm aabbee rrttoo nnoo qquuaa ll oo ppaarr tt iicc iippaannttee ddeevvee sseerr eexxcc lluuiiddoo.. 33.. sseeccrreettáárr iiaa//ccoo mmiitt êê eexxcc lluuii oo ppaarrtt iicc iippaannttee.. RReess ttrr iiççããoo :: DDeevvee ttee rr iinntteeggrr iiddaaddee,, sseennddoo aa eessttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. RRee ssttrr iiççããoo :: mmiinn ddee 77 dd iiaass úúttee iiss dd aa ddaattaa iinniicc iioo ddoo eevveennttoo 44.. ppaarrtt iicc iippaanntt ee éé eexxcc lluuiiddoo PPóóss-- CCoonndd :: -- CCoomm eexxcceeççããoo ddoo ppaarr tt iicc iippaannttee ssee rr uumm oouuvviinnttee,, ssee rráá eennvviiaaddoo ee-- mmaa iill ppaa rraa ooss oouuvviinnttee ss ssoobbrree aa aa lltteerraaççããoo ee ffee tt uuaaddaa.. -- RReesstt iitt uuiirr vvaa lloorr ddee iinnsscc rr iiççããoo ppaarraa ooss oouuvviinntteess ee//oouu aapprreesseennttaaddoorr.. SSee pprraazzoo ddaa eexxcc lluussããoo ffoo rr mmaa iioorr qquuee 55 dd iiaass úúttee iiss,, oo vvaa lloorr aa ss eerr rreess tt iitt uuííddoo sseerráá ddee 8800 %%

Título CCoonnss uullttaarr ppaa rrtt iicc iippaanntteess Objetivo PPrroocceedd iimmeennttoo ppaarr aa qquuaannddoo ddeessee jjaa-- ssee ccoonnhheecceerr oo ss ppaarr tt iicc iippaanntteess ddee uumm eevveennttoo ee mm

aabbeerrttoo oouu ffeecchhaaddoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ccoonnss uullttaa ddee ppaa rrtt iicc iippaannttee nnoo eevveennttoo

PPrréé ccoonndd :: SSeeccrreettáárr iiaa TTiippoo

AAttoorr PPrr iimmáá rr iioo Atores

CCoommiissssããoo TTiippoo AAttoorr



iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. SSee SSeeccrreettáárr iiaa//CCoo mmiissss ããoo iiddeenntt iiffiiccaa oo ppaarr tt iicc iippaanntt ee.. EEnnttããoo SSee SSeecc rreettáá rr iiaa //ccoo mmiissssããoo ssee lleecc iioonnaa tt iippoo ddee eevveennttoo EEnnttããoo ccoonnss uullttaa eevveennttoo ss eessppeecc ííffiiccooss ccoo mm ppaa rrtt iicc iippaannttee SSeennããoo ccoonnss uulltt aa eevveennttooss ccoo mm ppaarr tt iicc iippaanntt ee.. SSeennããoo SSee SSeecc rreettáá rr iiaa //ccoo mmiissssããoo ssee lleecc iioonnaa tt iippoo ddee eevveennttoo EEnnttããoo ccoonnss uullttaa ttooddooss oo ss ppaarr tt iicc iippaanntteess ddoo eevveennttoo ssee lleecc iioonnaaddoo SSeennããoo ccoonnss uulltt aa ttooddooss ooss pp aarrtt iicc iippaanntteess ee mm ttooddooss oo ss eevveennttoo ss 22.. ppaarrtt iicc iippaanntt eess ssããoo ccoonnss uullttaaddoo ss..

Título CCaaddaassttrraarr eevveennttoo Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo éé rreecceebb iiddoo ppee llaa ee mmpprree ssaa uumm eevveennttoo ppaarraa ggeerreenncc iiaarr Contexto SSiissttee mmaa ee mmiitt iinnddoo ccaaddaass ttrroo ddoo eevveennttoo

PPrréé ccoonndd :: Atores SSeeccrreettáárr iiaa TTiippoo



iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo..


11.. SSeeccrreettáárr iiaa ffoo rr nneeccee iinnffoorr mmaaççõõeess ssoobb rree oo eevveennttoo.. 22.. SSeeccrreettáá rr iiaa ccaaddaasstt rraa eevveennttoo.. RReesstt rr iiççããoo :: DDeevvee ttee rr iinntteeggrr iiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa dd ee ssaatt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. eevveennttoo éé ccaaddaass ttrraaddoo

Título CCaaddaassttrraarr ccoo mmiiss ssããoo Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee ccaaddaasstt rraarr aa ccoo mmiiss ssããoo oorr ggaanniizzaaddoorraa ddoo eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ccaaddaass ttrroo ddaa ccoo mmiiss ssããoo




iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. SSeeccrreettáárr iiaa ssee lleecc iioonnaa eevveennttoo ee mm aabbeerr ttoo.. 22.. SSeeccrreettáárr iiaa ffoo rr nneeccee iinnffoorr mmaaççõõeess ssoobb rree aa ccoo mmiissssããoo.. 33..SSeeccrreettáárr iiaa ccaaddaass ttrraa aa ccoo mmiissss ããoo.. RReess ttrr iiççããoo :: DDeevvee ttee rr iinntteeggrr iiddaaddee,, ss eennddoo aa eessttrraa ttééggiiaa ddee ssaatt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 44.. CCoommiissssããoo éé ccaadd aasstt rraaddaa

Título CCaaddaassttrraarr ccoo mmiitt êê Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee ccaaddaasstt rraarr oo ccoo mmiitt êê cc iieenntt ííffiiccoo ddoo eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ccaaddaass ttrroo ddoo ccoo mmiitt êê




iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. SSeeccrreettáárr iiaa ssee lleecc iioonnaa eevveennttoo ee mm aabbeerr ttoo.. 22.. SSeeccrreettáárr iiaa ffoo rr nneeccee iinnffoorr mmaaççõõeess ssoobb rree oo ccoo mmiittêê.. 33.. SSeeccrreettáárr iiaa ccaaddaa ssttrraa oo ccoo mmiittêê.. RReess ttrr iiççããoo :: DDeevvee ttee rr iinntteeggrr iidd aaddee,, sseennddoo aa eess ttrraa ttééggiiaa dd ee ssaatt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 44.. ccoo mmiitt êê éé ccaaddaass ttrraaddoo

Título RReecceebbeerr rreeccuurr ssooss Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo éé ffoorr nneecc iiddoo rreeccuurrssooss ppee llooss ppaa rrccee iirrooss ppaarraa oo eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ccaaddaass ttrroo ddee rreeccuurrssooss rreecceebb iiddoo ss

PPrréé ccoonndd :: 11.. rreeccuurrssooss ffoorraa mm ffoorr nneecc iiddooss

Atores SSeeccrreettáárr iiaa TTiippoo AAttoorr


Recursos EEvveennttoo,, rreeccuurrssoo ss Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. sseeccrreettáá rr iiaa ssee lleecc iioonnaa eevveennttoo aabbeerr ttoo qquuee ppoossss uuii rreeccuurr ssoo aa rreecceebb eerr.. 22.. sseeccrree ttaarr iiaa ssee lleecc iioonnaa rr eeccuurrssoo aa rr eecceebbeerr.. RRee ssttrr iiççããoo :: DDeevvee tteerr iinntteeggrr iiddaaddee,, sseennddoo aa eessttrraa ttééggiiaa ddee ssaatt iiss ffaaççããoo :: iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. rreeccuurrssoo éé rreecceebb iiddoo..

Título DDiiss ttrr iibbuuiirr rreeccuurrssoo ss Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo éé dd iiss ttrr iibbuuííddoo ooss rreeccuurrssoo ss ppaarraa ooss eevveennttooss


Contexto SSiissttee mmaa ee mmiitt iinnddoo dd iiss ttrr iibbuuiiççããoo ddee rreeccuurrssoo ss ppaarraa ooss eevveennttooss PPrréé ccoonndd :: 11.. rreeccuurrssooss ffoorraa mm rreecceebb iiddooss ppee llaa sseeccrree ttaarr iiaa



Recursos EEvveennttoo,, rreeccuurrssoo ss Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. sseeccrreettáá rr iiaa ssee lleecc iioonnaa rreeccuurrssoo rreecceebb iiddoo ee nnããoo dd iisstt rr iibbuuiiddoo 22.. sseeccrreettaa rr iiaa ssee lleecc iioonnaa aa tt iivviidd aaddee ((ss )) ddoo eevveennttoo aa sseerr rr ee llaacc iioonnaaddaa ccoo mm rreeccuurr ssoo.. RReesstt rr iiççããoo :: DDeevvee tt eerr iinntt eeggrr iiddaadd ee,, sseennddoo aa eessttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. rreeccuurrssoo éé dd iisstt rr iibbuuiiddoo..

Título PPaaggaarr ffoorr nneecceeddoo rr Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo oo ffoorr nneecceeddoorr aa iinnddaa nnããoo ffoo ii ppaaggoo ppee lloo rreeccuurr ssoo ffoorr nneecc iiddoo

ppaarraa oo eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ppaaggaa mmeennttoo ppoorr rreeccuurrssoo rreecceebb iiddoo ddoo ss eevveennttoo ss

PPrréé ccoonndd :: 11.. rreeccuurrssooss ffoorraa mm rreecceebb iiddooss ppee llaa sseeccrree ttaarr iiaa



Recursos EEvveennttoo,, rreeccuurrssoo Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. sseeccrreettáá rr iiaa ssee lleecc iioonnaa rreeccuurrssoo rreecceebb iiddoo ee nnããoo ppaaggoo 22.. sseeccrree ttaarr iiaa ppaaggaa ffoorr nneecceeddoo rr ddoo rreeccuurrssoo.. RReess ttrr iiççããoo :: DDeevvee tteerr iinntteeggrr iidd aaddee,, sseennddoo aa eessttrraa ttééggiiaa ddee ssaatt iiss ffaaççããoo :: iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. ffoo rr nneecceeddoorr éé pp aaggoo.. PPóóss-- ccoonndd :: 11.. FFoorrnneecceeddoorr rreecceebbee ppaaggaa mmeennttoo__rreeccuurrssoo

Título RReecceebbeerr pp aaggaa mmeennttoo Objetivo PPrroocceedd iimmeennttoo ppaarr aa qquuaannddoo aa sseecc rreettaa rr iiaa aa iinnddaa nnããoo rreecceebbeeuu ppaaggaa mmeennttoo rree ffee rreennttee aa

iinnssccrr iiççããoo ddoo oouuvviinnttee ee//oouu aapp rreesseennttaaddoorr Contexto SSiissttee mmaa ee mmiitt iinnddoo ppaaggaa mmeennttoo ddee iinnssccrr iiççããoo

PPrréé ccoonndd :: 11.. OOuuvviinntt ee ee//oouu aapp rreesseenntt aaddoorr eess ttããoo iinnss ccrr iittooss nnoo eevveennttoo 22.. OOuuvviinntt ee ee//oouu aapp rreesseenntt aaddoorr ee ffee tt uuoouu ppaaggaa mmeennttoo



Recursos EEvveennttoo,, rreeccuurrssoo Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. sseeccrreettáá rr iiaa iiddeenntt iiff iiccaa oouuvviinnttee//aapp rreesseennttaaddoorr 22.. sseeccrreettaa rr iiaa rreecceebbee ppaaggaa mmeennttoo.. RReess ttrr iiççããoo :: DDeevvee ttee rr iinntteeggrr iiddaaddee,, ss eennddoo aa eessttrraa ttééggiiaa ddee ssaatt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. ppaaggaa mmeennttoo éé rreecceebb iiddoo..

Título CCoonnss uullttaarr pp rrooggrraa mmaaççããoo Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee ccoonnhheecceerr aa pprrooggrraa mmaaççããoo ddoo eevveennttoo


Contexto SSiissttee mmaa ee mmiitt iinnddoo ccoonnss uullttaa ddee pprrooggrraa mmaaççããoo ddoo eevveennttoo

ppaarrtt iicc iippaanntt ee TTiippoo AAttoo rr PPrr iimmáá rr iioo ppaarrccee iirroo ss TTiippoo aa ttoorr pprr iimmaa rr iioo cc lliieennttee TTiippoo aa ttoorr sseeccuunndd aarr iioo

Atores

CClliieennttee iinnssccrr iittoo TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo,, pp rrooggrraa mmaaççããoo Episódios 11.. ppaarrtt iicc iippaanntt ee//ppaarr ccee iirroo ss//cc lliieennttee//cc lliieennttee iinnssccrr iittoo ssee lleecc iioonnaa eevveennttoo

22.. ppaarrtt iicc iippaanntt ee//ppaarr ccee iirroo ss//cc lliieennttee//cc lliieennttee iinnssccrr iittoo ccoonnss uullttaa pp rrooggrraa mmaaççããoo ddoo eevveennttoo.. 33.. pprrooggrraa mmaaççããoo éé ccoonnss uullttaaddaa..

Título IInnssccrreevvee rr-- ssee ee mm eevveennttoo Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo oo cc lliieennttee iinnssccrr iittoo ddee sseejjaa ssee ccaaddaass ttrraarr ee mm uumm eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ccaaddaass ttrroo ddee iinnssccrr iiççããoo nnoo eevveennttoo Atores CClliieennttee iinnssccrr iittoo TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo,, iinnssccrr iiççããoo Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. cc lliieennttee iinnsscc rr iittoo ssee lleecc iioonnaa eevveennttoo ee mm aabbeerrttoo 22.. cc lliieennttee ssoo lliicc iitt aa iinnssccrr iiççããoo.. RReesstt rr iiççããoo :: DDeevvee tteerr iinntteeggrr iiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa dd ee ssaatt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo 33.. SSee CCPPFF__cc lliieennttee eennttããoo iinnssccrr iiççããoo éé ccaaddaass ttrraaddaa.. .. RReess ttrr iiççããoo :: SSee VVaa lliiddaa rr ss iitt uuaaççããoo eennttããoo aapp lliiccaarr ddee ssccoonnttoo sseennããoo ssee vveerr iiff iiccaarr ppoo tteenncc iiaa ll eennttããoo ee mmiitt iirr ccaarr ttããoo.. PPooss ccoonndd :: 11.. eeffeett uuaarr pp aaggaa mmeennttoo ddee iinnss ccrr iiççããoo

Título EEnnvviiaa rr ttrr aabbaa llhhoo Objetivo PPrroocceedd iimmeennttoo ppaa rraa qquuaannddoo oo aapprreesseennttaaddoorr ddeessee jjaa eennvviiaarr ttrraabb aa llhhoo pp aarraa ssee lleeççããoo ee mm

eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ccaaddaass ttrroo ddee tt rraabbaa llhhoo Ator aapprreesseennttaaddoo rr TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo,, ttrraabbaa llhhoo Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. aapprreesseennttaaddoo rr ssee lleecc iioonnaa eevveennttoo ee mm aabbeerr ttoo 22.. aapprreesseennttaaddoo rr iiddeenntt iiffiiccaa tt rraabbaa llhhoo.. RReess ttrr iiççããoo :: DDeevvee ttee rr iinntteeggrr iiddaaddee,, ss eennddoo aa eessttrraa ttééggiiaa ddee ssaatt iiss ffaaççããoo :: iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. aapprreesseennttaaddoo rr ccaaddaass ttrraa ttrraabbaa llhhoo 44.. ttrraabbaa llhhoo éé eennvviiaaddoo..

Título EEffee tt uuaarr ppaaggaa mmeennttoo Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo oo oouuvviinntt ee oouu aapprreesseennttaaddoorr ddee sseejjaa mm ppaaggaarr aa iinnssccrr iiççããoo ee mm

uumm eevveennttoo Contexto SSiissttee mmaa ee ffee tt uuaannddoo ppaaggaa mmeennttoo ddee iinnssccrr iiççããoo nnoo eevveennttoo

aapprreesseennttaaddoo rr TTiippoo aa ttoorr pprr iimmaa rr iioo Atores oouuvviinnttee TTiippoo aa ttoorr pprr iimmaa rr iioo

Recursos EEvveennttoo,, ppaaggaa mmeennttoo Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. aapprreesseennttaaddoo rr//oouuvviinnttee ss ee lleecc iioonnaa eevveennttoo ee mm aabbee rrttoo nnoo qquuaa ll eessttaa iinnsscc rr iittoo 22.. aapprreesseennttaaddoorr //oouuvviinnttee ee ffeett uuaa ppaaggaa mmeennttoo.. RReess ttrr iiççããoo :: DDeevvee ttee rr iinntteeggrr iiddaaddee,, sseennddoo aa


eessttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. RReess ttrr iiççããoo :: SSee vvaa lliiddaarr cc lliieenntt ee eennttããoo aapp lliiccaarr ddee ssccoonnttoo.. 44.. ppaaggaa mmeennttoo éé ee ffeett uuaaddoo.. PPooss ccoonndd :: 11.. ppaaggaa mmeennttoo éé rreecceebb iiddoo pp ee llaa sseeccrreett áárr iiaa

Título EEnnvviiaa rr ppaa llee ssttrraa Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo oo ppaa lleess ttrraannttee ddeessee jjaa eennvviiaa rr ppaa llee ssttrraa pp aarraa ssee lleeççããoo ee mm

eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ccaaddaass ttrroo ddee iinnssccrr iiççããoo nnoo eevveennttoo Atores ppaa lleesstt rraannttee TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo,, ppaa lleess ttrraa Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. ppaa lleesstt rraannttee ssee lleecc iioonnaa eevveennttoo ee mm aabbee rrttoo 22.. ppaa lleess ttrraanntt ee iiddeenntt iiffiiccaa ppaa lleess ttrraa.. RReess ttrr iiççããoo :: DDeevvee tteerr iinntteeggrr iiddaaddee,, sseennddoo aa ee ssttrraa ttééggiiaa ddee ssaatt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. ppaa lleesstt rraannttee ccaaddaasstt rraa ppaa llee ssttrr aa 44.. ppaa lleesstt rraa éé eennvviiaaddoo..

Título EEnnvviiaa rr mmaa tteerr iiaa ll Objetivo PPrroocceedd iimmeennttoo ppaa rraa qquuaannddoo oo mmiinn iisstt rraannttee ddeessee jjaa eennvviiaarr mmaa tteerr iiaa ll ppaarraa ssee lleeççããoo ee mm

eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ccaaddaass ttrroo ddee iinnssccrr iiççããoo nnoo eevveennttoo Atores mmiinniiss ttrraannttee TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo,, mmaattee rr iiaa ll Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. mmiinniiss ttrraannttee ssee lleecc iioonnaa eevveennttoo ee mm aabbeerr ttoo 22.. mmiinniiss ttrraannttee iiddeenntt iiff iiccaa mmaattee rr iiaa ll.. RReess ttrr iiççããoo :: DDeevvee tteerr iinntteeggrr iiddaaddee,, sseennddoo aa eessttrraa ttééggiiaa ddee ssaatt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. mmiinniiss ttrraannttee ccaaddaa ssttrraa mmaatt eerr iiaa ll 44.. mmaatteerr iiaa ll éé eennvviiaaddoo..

Título EEnnvviiaa rr rreeqquuiiss iiççããoo Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo oo mmiinniiss ttrraannttee ddeessee jjaa eennvviiaa rr rreeqquuiiss iiççaaoo ee mm eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ccaaddaass ttrroo ddee rreeqquuiiss iiççaaoo nnoo eevveennttoo Atores mmiinniiss ttrraannttee TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo,, rreeqquuiiss iiççaaoo Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. mmiinniiss ttrraannttee ssee lleecc iioonnaa eevveennttoo ee mm aabbeerr ttoo 22.. mmiinniiss ttrraanntt ee iidd eenntt iiffiiccaa rreeqquuiiss iiççããoo.. RReess ttrr iiççããoo :: DDeevvee ttee rr iinntteeggrr iiddaaddee,, sseennddoo aa eessttrraa ttééggiiaa ddee ssaatt iiss ffaaççããoo :: iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. mmiinniiss ttrraannttee ccaaddaa ssttrraa rreeqquuiiss iiççããoo 44.. rreeqquuiiss iiççããoo éé eennvviiaaddaa..

Título SSeelleecc iioonnaa rr mmiinniiss ttrraanntt ee Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee ssee lleecc iioonnaarr oo mmiinniiss ttrr aannttee ppaa rraa oo eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ssee lleeççããoo ddee mmiinniiss ttrraannttee


Atores ccoo mmiissss ããoo TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. ccoo mmiissss ããoo ssee lleecc iioonnaa vvaaggaa ss nnooss hhoorráá rr iiooss ddee pp rrooggrraa mmaaççããoo ddoo eevveennttoo ee mm aabbee rrttoo 22.. ccoo mmiiss ssããoo iiddeenntt iiffiiccaa mmiinniiss ttrraanntt ee.. RReesstt rr iiççããoo :: DDeevvee ttee rr iinntteeggrr iiddaaddee,, sseennddoo aa eessttrraa ttééggiiaa ddee ssaatt iiss ffaaççããoo :: iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. ccoo mmiissss ããoo ccaaddaass ttrraa mmiinniiss ttrraannttee 44.. mmiinniiss ttrraannttee éé ssee lleecc iioonnaaddoo.. PPooss ccoonndd :: 11.. ÉÉ eennvviiaaddoo ee-- mmaa iill ppaa rraa oo mmiinniiss ttrraannttee ccoo mm oo ccoonnvviittee ddoo eevveennttoo ccoonntteennddoo :: aassss uunnttoo dd ee iinntteerree ssssee ddoo ccuurrssoo,, pprraazzoo eesstt iimmaaddoo ppaarraa oo eennvviioo ddoo mmaattee rr iiaa ll ee aaccee iittaaççããoo ddoo ccoonnvviittee ee iinnffoorr mmaaççõõeess ggee rraa iiss ssoobbrree oo eevveennttoo

Título SSeelleecc iioonnaa rr ppaa lleess ttrraannttee Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee ssee lleecc iioonnaarr oo ppaa lleesstt rraannttee pp aarraa oo eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ssee lleeççããoo ddee ppaa llee ssttrr aannttee Atores ccoo mmiissss ããoo TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. ccoo mmiissss ããoo ssee lleecc iioonnaa vvaaggaa ss nnooss hhoorráá rr iiooss ddee pp rrooggrraa mmaaççããoo ddoo eevveennttoo ee mm aabbee rrttoo 22.. ccoo mmiiss ssããoo iidd eenntt iiffiiccaa ppaa lleess ttrraannttee.. RReess ttrr iiççããoo :: DDeevvee tteerr iinntteeggrr iiddaaddee,, sseennddoo aa ee ssttrraa ttééggiiaa ddee ssaatt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. ccoo mmiissss ããoo ccaaddaass ttrraa ppaa lleesstt rraannttee 44.. ppaa lleesstt rraannttee éé ssee lleecc iioonnaaddoo.. PPooss ccoonndd :: 11.. ÉÉ eennvviiaaddoo ee-- mmaa iill ppaa rraa oo ppaa lleesstt rraannttee ccoo mm oo ccoonnvviittee ddoo eevveennttoo ccoonntteennddoo :: aa ssss uunnttoo dd ee iinntteerree ssssee ddoo ccuurrssoo,, pp rraazzoo eesstt iimmaaddoo ppaa rraa oo eennvviioo ddaa ppaa llee ssttrr aa ee aaccee iittaaççããoo ddoo ccoonnvviittee ee rreeqquuiiss iiççããoo ee iinnffoorr mmaaççõõeess ggeerr aa iiss ssoobb rree oo eevveennttoo

Título EEmmiitt iirr ccrraacchhááss Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee ee mmiitt iirr ccrraacchhááss pp aarraa ooss ppaa rrtt iicc iippaanntteess ddoo eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ccrraacchháá ss ppaarraa ppaa rrtt iicc iippaanntteess Atores ccoo mmiissss ããoo TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo,, cc rraacchháá Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. ccoo mmiissss ããoo ssee lleecc iioonnaa eevveennttoo ee mm aabb eerrttoo 22.. ccoo mmiissss ããoo ssee lleecc iioonnaa ppaa rrtt iicc iippaanntteess ddoo eevveennttoo 33.. ccoo mmiissss ããoo ssoo lliicc iittaa iimmpprreess ssããoo ddoo ccrraacchháá 44.. ccrraacchháá éé ee mmiitt iiddoo.. PPooss ccoonndd :: 11.. ccrraacchháá éé eennvviiaaddoo aaoo ppaarr tt iicc iippaannttee

Título EEmmiitt iirr cceerr tt iiffiiccaaddoo ss Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo dd eesseejjaa-- ssee ee mmiitt iirr ccee rrtt iiffiiccaaddoo ddee ppaarr tt iicc iippaaççããoo ppaarraa oo ss

ppaarrtt iicc iippaanntt eess ddoo eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ccrraacchháá ss ppaarraa ppaa rrtt iicc iippaanntteess Atores ccoo mmiissss ããoo TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo,, cceerrtt iiff iiccaaddoo Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::


iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. ccoo mmiissss ããoo ssee lleecc iioonnaa eevveennttoo ffeecchhaaddoo.. 22.. ccoo mmiissss ããoo ssee lleecc iioonnaa ppaa rrtt iicc iippaanntteess ddoo eevveennttoo.. CCoo mm nnoo mmíínnii mmoo 8855%% pprree sseennççaa.. 33.. ccoo mmiissss ããoo ssoo lliicc iittaa iimmpprreess ssããoo ddoo cceerr tt iiffiiccaaddoo 44.. cceerrtt iiffiiccaaddoo éé ee mmiitt iiddoo.. PPooss ccoonndd :: 11.. cceerrtt iiffiiccaaddoo éé eennvviiaaddoo aaoo ppaa rrtt iicc iippaannttee

Título AAtt uuaa lliizzaa rr pprrooggrraa mmaaççããoo Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee ee llaabboorraa rr aa pprrooggrr aa mmaaççããoo ddoo eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo aatt uuaa lliizzaaççããoo ddaa ppaarr tt iicc iippaanntteess Atores ccoo mmiissss ããoo TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo,, pp rrooggrraa mmaaççããoo Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. ccoo mmiissss ããoo ssee lleecc iioonnaa eevveennttoo ee mm aabb eerrttoo.. 22.. ccoo mmiissss ããoo iiddeenntt iiffiiccaa pprrooggrraa mmaaççããoo.. 33.. ccoo mmiiss ssããoo aatt uuaa lliizzaa pprrooggrraa mmaaççããoo.. RReess ttrr iiççããoo :: DDeevvee tt eerr iinntteeggrr iiddaaddee,, sseennddoo aa eessttrraa ttééggiiaa ddee ssaatt iiss ffaaççããoo :: iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 44.. pprrooggrraa mmaaççããoo éé aatt uuaa lliizzaadd aa..

Título CCaaddaassttrraarr ppaa rrccee iirrooss Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee ccaaddaasstt rraarr ppaarr ccee iirroo ss nnooss eevveennttooss Contexto SSiissttee mmaa ee mmiitt iinnddoo oo ccaaddaass ttrroo ddee ppaarr ccee iirroo ss Atores ccoo mmiissss ããoo TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. ccoo mmiissss ããoo ssee lleecc iioonnaa eevveennttoo ee mm aabb eerrttoo.. 22.. ccoo mmiissssããoo iiddeenntt iiffiiccaa ppaarrccee iirrooss.. RRee sstt rr iiççããoo :: DDeevvee ttee rr iinntteeggrr iiddaaddee,, sseennddoo aa ee ssttrraa ttééggiiaa ddee ssaatt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. ppaarrccee iirroo ss ssããoo ccaaddaa ssttrraaddoo ss..

Título SSeelleecc iioonnaa rr ttrraabb aa llhhoo Objetivo PPrroocceedd iimmeennttoo ppaarr aa qquuaannddoo ddeessee jjaa-- ssee ssee lleecc iioonnaarr ttrraabb aa llhhooss aa sseerree mm aapprree sseennttaaddoo ss nnoo

eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo aa ssee lleeççããoo ddee tt rraabbaa llhhoo ss Atores ccoo mmiitt êê TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo,, pp rrooggrraa mmaaççããoo,, tt rraabbaa llhhoo ss Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. ccoo mmiitt êê ssee lleecc iioonnaa eevveennttoo ee mm aabb eerrttoo.. 22.. CCoommiittêê ssee lleecc iioonnaa pprrooggrraa mmaaççããoo 22.. ccoo mmiittêê iiddeenntt iiff iiccaa ttrraabbaa llhhoo.. RReess ttrr iiççããoo :: DDeevvee ttee rr iinntteeggrr iiddaaddee,, sseennddoo aa eess ttrraatt ééggiiaa dd ee ssaatt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. ttrraabbaa llhhoo éé ssee lleecc iioonnaaddoo.. PPooss ccoonndd :: 11.. ÉÉ eennvviiaaddoo ee-- mmaa iill ppaarr aa oo aapprreesseennttaaddoorr ppaarr aabbeenniizzaannddoo ppee lloo ttrr aabbaa llhhoo ssee lleecc iioonnaaddoo ee sseeuu hhoo rráárr iioo pprreevviissttoo ddee aapp rreesseennttaaççããoo ee ssoo lliicc iittaaççããoo ddoo pp aaggaa mmeennttoo ddaa iinnss ccrr iiççããoo nnoo eevveennttoo

Título FFoorrnneecceerr rreeccuurrssooss


Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee ccaaddaasstt rraarr rreeccuurrssooss ppaa rraa oo eevveennttoo Contexto SSiissttee mmaa ee mmiitt iinnddoo ccaaddaass ttrroo ddee rreeccuurrssooss Atores ppaarrccee iirroo ss TTiippoo aa ttoorr pprr iimmaa rr iioo Recursos EEvveennttoo Episódios RReesstt rr iiççããoo :: DDeevvee tteerr ccoonnffiiddeenncc iiaabb iilliiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa ddee ssaa tt iiss ffaaççããoo ::

iidd eenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 11.. ppaarrccee iirroo ss ssee lleecc iioonnaa eevveennttoo ee mm aabbeerrttoo ccoo mm rreeccuurrssooss aa rreecceebbee rr ppoorr ee llee.. 22.. ppaarrccee iirroo iiddeenntt iiffiiccaa rreeccuurrssoo.. RReess ttrr iiççããoo :: DDeevvee tteerr iinntteeggrr iiddaaddee,, sseennddoo aa eess ttrraa ttééggiiaa dd ee ssaatt iiss ffaaççããoo :: iiddeenntt iiffiiccaaççããoo,, aauutteenntt iiccaaççããoo.. 33.. rreeccuurrssoo éé ffoorr nneecc iiddoo.. PPooss ccoonndd :: 11.. sseeccrreettaa rr iiaa rreecceebbee rr eeccuurrssooss

Título VVaa lliiddaarr ss iitt uuaaççããoo Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee vvee rr iiffiiccaarr ss iitt uuaaççããoo ddoo cc lliieenntt ee iinnsscc rr iittoo Contexto SSiissttee mmaa rree ttoorr nnaa tt rr uuee ppaarraa oo ccaassoo ddee ssee rr uumm cc lliieennttee vviipp,, ccaa ssoo ccoonntt rraarr iioo rreettoo rr nnaa ffaa llssee

PPrréé-- ccoonndd :: 11.. rreecceebbee ccoo mmoo eennttrraaddaa aa iiddeenntt iiffiiccaaççããoo ddoo cc lliieennttee iinnssccrr iittoo

Atores RROO TTiippoo aa ttoorr Recursos Episódios 11.. ssee lleecc iioonnaarr tt iippoo cc lliieennttee

22.. SSee tt iippoo__cc lliieenntt ee == vviipp eennttããoo rree ttoorr nnaa ttrr uuee sseennããoo rreettoo rr nnaa ffaa llssee

Título AApp lliiccaarr ddeessccoonnttoo Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee vvee rr iiffiiccaarr ss iitt uuaaççããoo ddoo cc lliieenntt ee iinnsscc rr iittoo Contexto SSiissttee mmaa rree ttoorr nnaa vvaa lloorr iinnssccrr iiççããoo ccoo mm ddee ssccoonnttoo aapp lliiccaaddoo ddee 3300%%

11.. rreecceebbee ccoo mmoo eennttrraaddaa vvaa lloorr iinnssccrr iiççaaoo Atores RROO TTiippoo aa ttoorr Recursos Episódios 11.. rreettoorr nnaa vvaa lloorr iinnssccrr iiççããoo ::== vvaa lloorr iinnssccrr iiççããoo-- 3300%%

Título VVeerr iiffiiccaa rr ppootteenncc iiaa ll Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee vvee rr iiffiiccaarr oo ppoo tteenncc iiaa ll ddoo cc lliieennttee iinnss ccrr iittoo Contexto SSiissttee mmaa rree ttoorr nnaa ttrr uuee ppaarraa oo ccaassoo ddee ssee rr uumm cc lliieennttee vviipp ee mm ppoo tteenncc iiaa ll,, ccaa ssoo ccoonntt rraarr iioo

rreettoorr nnaa ffaa llss ee PPrréé-- ccoonndd :: 11.. rreecceebbee ccoo mmoo eennttrraaddaa aa iiddeenntt iiffiiccaaççããoo ddoo cc lliieennttee iinnssccrr iittoo

Atores RROO TTiippoo aa ttoorr Recursos Episódios 11.. ssee lleecc iioonnaarr ttoo ttaa ll ddee eevveennttooss aannuuaa iiss nnooss qquuaa iiss oo cc lliieennttee iinnssccrr iittoo ppaarr tt iicc iippoouu

22.. SSee ttoottaa ll >>33 eennttããoo rreettoorr nnaa ttrr uuee sseennããoo rree ttoorr nnaa ffaa llssee

Título EEmmiitt iirr ccaarr ttããoo Objetivo PPrroocceedd iimmeennttoo ppaarraa qquuaannddoo ddeesseejj aa-- ssee ee mmiittrr ccaa rrttããoo vviipp Contexto SSiissttee mmaa ee mmiitt iinnddoo ccaarr ttããooVVIIPP

PPrréé-- ccoonndd :: 11.. rreecceebbee ccoo mmoo eennttrraaddaa aa iiddeenntt iiffiiccaaççããoo ddoo cc lliieennttee iinnssccrr iittoo

Atores RROO TTiippoo aa ttoorr Recursos Episódios 11.. CCaarrttããoo éé iimmpprreess ssoo


Título CCPPFF__cc lliieennttee Objetivo PPrroocceedd iimmeennttoo ppaa rraa qquuaannddoo ddee sseejjaa-- ssee ssaabb eerr aa ss iitt uuaaççããoo jj uunnttoo aaooss óórr ggããooss ccoo mmppee tteennttee ss

ssoobbrree aa ss iitt uuaaççããoo ddoo cc lliieennttee Contexto SSiissttee mmaa ee mmiitt iinnddoo CCPPFF__CClliieennttee

PPrréé-- ccoonndd :: 11.. rreecceebbee ccoo mmoo eennttrraaddaa oo CCPPFF ddoo cc lliieenntt ee

Atores ss iissttee mmaa TTiippoo aa ttoorr Recursos Episódios 11.. CCoonnss uullttaa óórr ggããoo ss ccoo mmppee tteennttee ss

22.. rreettoorr nnaa ttrr uuee ss ee ss iitt uuaaççããoo ookk,, sseennããoo rreettoo rr nnaa ffaa llssee

55..55..33 AAnnaalliissaannddoo ooss cceennáárriiooss

Vale observar que muitos cenários serão incluídos nesta fase, pois nem todos

os cenários identificados ao se descrever os episódios3 foram definidos no LEL como

verbo, observando-se as regras para construção de cenários de acordo com o LEL (Leite,

1997).

Um outro ponto interessante foi a inclusão das estratégias de satisfação dos

requisitos organizacionais como cenários.

A análise dos cenários está ligada ao fato de que precisamos validar e verificar

os cenários com os clientes a fim de identificar erros, omissões e/ou ampliar informações

de episódios. Seguindo os passos para a construção de cenários deve-se unificar os

cenários se eles possuírem o mesmo objetivo ou mesmos episódios.

55..66 FFaassee 33 –– DDeeffiinniiççããoo ddee AAssppeeccttooss CCaannddiiddaattooss

A definição dos aspectos candidatos foi realizada seguindo as diretrizes

propostas no capítulo 4.

Assim, primeiramente, identificamos os requisitos não funcionais como

aspectos candidatos, outros aspectos podem ser identificados levando-se em consideração

os outros passos das diretrizes apontadas na fase 3.

3 Cysneiros (2002) realiza a descrição dos cenários de forma bem sucinta, sendo de poucas palavras, utilizando-se o principio do vocabulário mínimo, não sendo portanto, rico em detalhes. Breitman (2000) descreve os cenários de forma bem detalhada, inclusive fazendo referencias as telas usadas no acesso. Usaremos o meio termo, não seremos tão detalhistas e nem tão vagos nas nossas descrições. Quando a situação for julgada necessária, seremos mais detalhistas.


Deste modo, foram identificados quatro aspectos candidatos no nosso estudo de

caso:

· Confidenciabilidade – Requisito não funcional requisitado pela maioria

dos cenários;

· Integridade - Requisito não funcional requisitado por todos os cenários

onde exige a atualização;

· CPF_Cliente – foi definido como aspecto por se tratar de uma restrição

que pode ser aplicada em outros cenários e outros projetos, sem que a

funcionalidade básica seja alterada caso venha a ser retirado;

· Validar Situação – foi definido como aspecto por se tratar de uma

constraint organizacional que pode ser aplicada em outros cenários e

em outros projetos.

A tabela 5.9 relaciona os aspectos encontrados com os cenários

correspondentes e sua influência sobre eles.


TABELA 5.9– CONTRIBUIÇÕES DOS ASPECTOS

Aspectos Candidatos Confidenciabilidade

Integridade

CPF_Cliente

Validar

Situação

iden

tifi

cad

or

Cenário

- + - + - + - + 11 AAlltt eerraarr

ppaarrtt iicc iippaanntt ee X X

22 EExxcc lluuiirr ppaarrtt iicc iippaanntt ee

X X

33 CCoonnss uullttaarr ppaarrtt iicc iippaanntt eess

X

44 CCaaddaassttrraarr eevveennttoo X X 55 CCaaddaassttrraarr

ccoo mmiissss ããoo X X

66 CCaaddaassttrraarr ccoo mmiitt êê X X 77 RReecceebbeerr rreeccuurr ssooss X X 88 DDiiss ttrr iibbuuiirr rreeccuurrssoo ss X X 99 PPaaggaarr ffoorr nneecceeddoo rr X X 1100 RReecceebbeerr

ppaaggaa mmeennttoo X X

1111 CCoonnss uullttaarr pprrooggrraa mmaaççããoo

X

1122 IInnssccrreevvee rr-- ssee ee mm eevveennttoo

X X X X

1133 EEnnvviiaa rr ttrr aabbaa llhhoo X X 1144 EEffee tt uuaarr

ppaaggaa mmeennttoo X X X

1155 EEnnvviiaa rr ppaa llee ssttrraa X X 1166 CCaaddaassttrraarr

ppaarrccee iirroo ss X X

1177 EEnnvviiaa rr mmaa tteerr iiaa ll X X 1188 EEmmiitt iirr cceerr tt iiffiiccaaddoo ss X X 1199 AAtt uuaa lliizzaa

pprrooggrraa mmaaççããoo X X

2200 SSeelleecc iioonnaa rr ttrraabbaa llhhoo

X X

2211 FFoorrnneecceerr rreeccuurrssooss X X 2222 SSeelleecc iioonnaa rr

mmiinniiss ttrraannttee X X

2233 SSeelleecc iioonnaa rr ppaa lleesstt rraannttee

X X

2244 EEmmiitt iirr ccrraacchhááss X X 2255 EEnnvviiaa rr rreeqquuiiss iiççããoo X X


O aspecto CPF_Cliente apesar de inicialmente se tratar de uma restrição onde o

usuário seja o prejudicado em termos de tempo (pois pode demorar um pouco mais para

ser verificado), foi definido como positivo pois garante uma confiabilidade das

informações que estão sendo prestadas, ou seja, o cliente é fidedigno.

Para definir a composição entre os aspectos, ou seja, como será realizada a

chamada para a execução do aspecto, usa-se o modelo proposto na Fase 3 do Capitulo 4.

A tabela 5.10 foi especificada para cada aspecto candidato de acordo com o

proposto pela DAORE.

TABELA 5.10 –. COMPOSIÇÃO DOS ASPECTOS IDENTIFICADOS

ASPECTO CANDIDATO: AC#1 - Confidenciabilidade

CENARIO AFETADO CONDIÇÃO REGRA DE

COMPOSIÇÃO PONTO DE

JUNÇÃO INFORMAÇÕES ADICIONAIS

CCNN ## 11 -- AA lltteerraarr pp aarrtt iicciipp aann ttee

-

WRAP 1 Se situaçãoOK então executa(ponto junção) Senão exibe(msgErro)

CCNN ## 22 -- EExxcc lluu ii rr pp aarrtt iicciipp aann ttee

-


CCNN ## 33 -- CCoo nn ss uu llttaarr pp aarrtt iicciipp aann tteess

-


CCNN ## 44 -- CCaadd aass tt rraarr eevv eenn ttoo -


CCNN ## 55 -- CCaadd aass tt rraarr ccoo mmiiss ss ããoo -


CCNN ## 66 -- CCaadd aass tt rraarr ccoo mmiittêê -


CCNN ## 77 -- RReecceebb eerr

rreeccuu rrss ooss -


CCNN ## 88 -- DD iiss tt rriibb uu iirr rreeccuu rrss ooss -


CCNN ## 99 -- PPaagg aarr

ffoo rrnn eecceedd oo rr -


CCNN ## 11 00 -- RReecceebb eerr pp aagg aammeenn ttoo -



CCNN ## 11 11 -- CCoo nn ss uu llttaarr

pp rroo gg rraammaaççããoo -


CCNN ## 11 22 -- IInn ss ccrreevv eerr--ss ee eemm eevv eenn ttoo -


CCNN ## 11 33 -- EEnn vv iiaa rr

tt rraabb aallhh oo -


CCNN ## 11 44 -- EEffeettuu aarr pp aagg aammeenn ttoo -



pp aalleess tt rraa -


CCNN ## 11 66 -- CCaadd aass tt rraarr pp aarrcceeiirroo ss

-



mmaatteerr iiaa ll -


CCNN ## 11 88 -- EEmmiitt iirr cceerrtt iiff iiccaadd oo ss -


CCNN ## 11 99 -- AA ttuu aalliizzaa



CCNN ## 22 00 -- SSee lleecc iioo nn aarr tt rraabb aallhh oo -


CCNN ## 22 11 -- FFoo rrnn eecceerr rreeccuu rrss ooss -


CCNN ## 22 22 -- SSee lleecc iioo nn aarr mmiinn iiss tt rraann ttee -


CCNN ## 22 33 -- SSee lleecc iioo nn aarr pp aalleess tt rraann ttee -


CCNN ## 22 44 -- EEmmiitt iirr ccrraacchh ááss -


CCNN ## 22 55 -- EEnn vv iiaa rr rreeqq uu iiss iiççããoo -



ASPECTO CANDIDATO: AC#2 - Integridade




CCNN ## 11 -- AA lltteerraarr pp aarrtt iicciipp aann ttee

-


CCNN ## 22 -- EExxcc lluu ii rr pp aarrtt iicciipp aann ttee

-


CCNN ## 44 -- CCaadd aass tt rraarr

eevv eenn ttoo -


CCNN ## 55 -- CCaadd aass tt rraarr ccoo mmiiss ss ããoo

-


CCNN ## 66 -- CCaadd aass tt rraarr ccoo mmiittêê

-


CCNN ## 77 -- RReecceebb eerr rreeccuu rrss ooss

-


CCNN ## 88 -- DD iiss tt rriibb uu iirr

rreeccuu rrss ooss -


CCNN ## 99 -- PPaagg aarr ffoo rrnn eecceedd oo rr

-


CCNN ## 11 00 -- RReecceebb eerr pp aagg aammeenn ttoo

-


CCNN ## 11 22 -- IInn ss ccrreevv eerr--ss ee

eemm eevv eenn ttoo -



tt rraabb aallhh oo -


CCNN ## 11 44 -- EEffeettuu aarr pp aagg aammeenn ttoo

-


CCNN ## 11 55 -- EEnn vv iiaa rr pp aalleess tt rraa

-



CCNN ## 11 66 -- CCaadd aass tt rraarr

pp aarrcceeiirroo ss -


CCNN ## 11 77 -- EEnn vv iiaa rr mmaatteerr iiaa ll

-


CCNN ## 11 88 -- EEmmiitt iirr cceerrtt iiff iiccaadd oo ss

-


CCNN ## 11 99 -- AA ttuu aalliizzaa



CCNN ## 22 00 -- SSee lleecc iioo nn aarr tt rraabb aallhh oo

-


CCNN ## 22 11 -- FFoo rrnn eecceerr rreeccuu rrss ooss

-


CCNN ## 22 22 -- SSee lleecc iioo nn aarr mmiinn iiss tt rraann ttee

-


CCNN ## 22 33 -- SSee lleecc iioo nn aarr

pp aalleess tt rraann ttee -


CCNN ## 22 44 -- EEmmiitt iirr ccrraacchh ááss

-


CCNN ## 22 55 -- EEnn vv iiaa rr rreeqq uu iiss iiççããoo

-


ASPECTO CANDIDATO: AC#3 - CPF_CLIENTE




CCNN ##1122 -- IInnss ccrreevvee rr--ssee ee mm eevvee nnttoo

- wrap 3 Se situaçãoOK então executa(ponto junção) Senão exibe(msgErro)

ASPECTO CANDIDATO: AC#4 - VALIDAR SITUAÇÃO





CCNN ##1122 -- IInnss ccrreevvee rr--ssee ee mm eevvee nnttoo

- overlap.after| 3 Se situaçãoOK então executa(ponto junção) Senão exibe(msgErro)

CCNN ## 11 44 -- EEffee ttuu aarr

ppaagg aa mmee nntt oo - overlap.before| 2 SE SITUAÇÃOOK ENTÃO

EXECUTA(PONTO JUNÇÃO) SENÃO EXIBE(MSGERRO)

Agora se deve verificar se não há conflitos entre os aspectos candidatos. Eles

são identificados quando diferentes aspectos candidatos devem ser aplicados num mesmo

ponto de junção de um cenário com os mesmos operadores de composição.

Neste projeto, os aspectos relacionados à confiabilidade e integridade estão

com os mesmos operadores e mesmo pontos de junção. Assim, deve-se aplicar uma ordem

de precedência para definir qual será executado primeiro. No capitulo 4 descreve-se com

mais detalhes como fazer esta operação.

A tabela 5.11 apresenta a resolução dos conflitos.

TABELA 5.11 – RESOLUÇÃO DE CONFLITOS

Cenários AC#1 AC#2 CCNN ##11 -- AAlltteerr aarr ppaarr tt iicc iippaannttee P1-W =1º P1-W =2º CCNN ##22 -- EExxcc lluuiirr ppaarr tt iicc iippaannttee P1-W =1º P1-W =2º CCNN ##44 -- CCaaddaassttrraarr eevveennttoo P1-W =1º P1-W =2º CCNN ##55 -- CCaaddaassttrraarr ccoo mmiissssããoo P1-W =1º P1-W =2º CCNN ##66 -- CCaaddaassttrraarr ccoo mmiittêê P1-W =1º P1-W =2º CCNN ##77 -- RReecceebbeerr rreeccuurrssooss P1-W =1º P1-W =2º CCNN ##88 -- DDiisstt rr iibbuuiirr rreeccuurrssooss P1-W =1º P1-W =2º CCNN ##99 -- PPaaggaarr ffoo rr nneecceeddoorr P1-W =1º P1-W =2º CCNN ##1100 -- RReecceebbeerr ppaaggaa mmeennttoo P1-W =1º P1-W =2º CCNN ##1122 -- IInnssccrreevveerr-- ssee ee mm eevveennttoo P1-W =1º P1-W =2º CCNN ##1133 -- EEnnvviiaarr ttrraabbaa llhhoo P1-W =1º P1-W =2º CCNN ##1144 -- EEffeett uuaa rr ppaaggaa mmeennttoo P1-W =1º P1-W =2º CCNN ##1155 -- EEnnvviiaarr ppaa lleess ttrraa P1-W =1º P1-W =2º

CCNN ##1166 -- CCaaddaassttrraarr ppaarrccee iirroo ss P1-W =1º P1-W =2º CCNN ##1177 -- EEnnvviiaarr mmaattee rr iiaa ll P1-W =1º P1-W =2º CCNN ##1188 -- EEmmiitt iirr cceerrtt iiff iiccaaddooss P1-W =1º P1-W =2º CCNN ##1199 -- AAttuuaa lliizzaa pprrooggrr aa mmaaççããoo P1-W =1º P1-W =2º CCNN ##2200 -- SSeelleecc iioonnaarr ttrraabbaa llhhoo P1-W =1º P1-W =2º CCNN ##2211 -- FFoorrnneecceerr rreeccuurr ssooss P1-W =1º P1-W =2º CCNN ##2222 -- SSeelleecc iioonnaarr mmiinniiss tt rraannttee P1-W =1º P1-W =2º CCNN ##2233 -- SSeelleecc iioonnaarr ppaa lleesstt rraannttee P1-W =1º P1-W =2º CCNN ##2244 -- EEmmiitt iirr ccrraacchhááss P1-W =1º P1-W =2º CCNN ##2255 -- EEnnvviiaarr rreeqquuiiss iiççããoo P1-W =1º P1-W =2º


Observando a tabela 5.11 podemos deduzir que o aspecto candidato AC #1-

Confiabilidade será executado antes do aspecto candidato AC #2 – Integridade. Decisões

como estas devem ocorrer com vários aspectos a serem incluídos nos projetos. É

importante que seja tomado uma decisão por parte do gerente de projeto, clientes e

engenheiro de requisitos.

55..77 FFaassee 44 –– MMaappeeaammeennttoo ddee OOnnttoolloogg iiaass

Nesta fase aplicaremos o método proposto por Breitman (2003).

Neste método, os termos do léxico classificados como do tipo objeto e sujeito

serão mapeados em classes da ontologia; os termos classificados em verbo serão

mapeados para propriedades; os termos classificados como do tipo estado serão mapeados

para classes ou propriedades, dependendo de sua importância relativa para a ontologia; a

noção de cada termo é mapeada na descrição da respectiva classe; e através da lista de

impactos de cada termo do léxico mapeia-se o verbo em propriedades e o predicado em

restrições das classes.

A tabela 4.9, apresentada no Capítulo 4 apresenta um resumo das ações

realizadas durante o processo de mapeamento dos termos do LEL para ontologia.

Breitman (2003) define alguns passos (Figura 5.3) para o processo de

mapeamento e assim, seguiremos estes passos para a construção de ontologia do

gerenciamento de eventos.


FIGURA 5.3 – O PROCESSO DE MAPEAMENTO LEL – ONTOLOGIAS. BREITMAN(2003)

1 – Listar os termos alfabeticamente de acordo com seu tipo (verbo, objeto, sujeito ou estado) 2 – Fazer três listas: Propriedades, classes e axiomas. Na lista de classes cada entrada terá um nome, descrição (linguagem natural) e uma lista contendo zero ou mais restrições (função que relaciona a classe em questão a outras, de maneira não-taxonômica). As entradas na lista de axiomas terão nomes (labels) somente. 3 – Utilizando a lista de símbolos do léxico classificados como sujeito ou objeto, para cada termo:

3.1 – Adicionar uma nova classe a lista de classes. O nome da classe é o símbolo do léxico propriamente dito. A descrição da classe é a noção do termo.

3.1.1 – para cada impacto, 3.1.1.1 – checar se já não faz parte da lista de propriedades da ontologia 3.1.1.2 - Caso não faça parte da lista (a propriedade ainda não existe), adicionar

uma nova propriedade na lista (de propriedades). O nome da propriedade deve ser baseado no verbo utilizado para descrever o impacto.

3.1.1.2.1 – verificar consistências 3.1.1.3 – Na lista de classes, adicionar uma nova restrição para a classe em

questão. A restrição é formada pela classe + a propriedade (definida em 3.1.1.1) + a classe relacionada (essa classe é o objeto direto/indireto do verbo utilizado no impacto do símbolo do léxico. Usualmente é um termo do próprio léxico e aparece sublinhado)

3.1.1.4 – Checar se existem indicativos de negação no vocabulário mínimo que relacionem duas ou mais classes. Verificar se essas classes possuem um relacionamento do tipo disjuntos(exemplo: macho e fêmea).

3.1.1.4.1 – Se verdadeiro, adicionar o disjoint a lista de axiomas. 3.2 – Verificar consistência

4 – Utilizando a lista de símbolos classificados como tipo verbo, para cada termo: 4.1.1 – Checar se já faz parte da lista de propriedades da ontologia.

4.1.1.1 – Caso não faça parte da lista (a propriedade não existe), adicionar uma nova propriedade a lista (de propriedades). O nome da propriedade é o símbolo do léxico propriamente dito.

4.1.1.1.1 - Verificar consistência 5 – Utilizando a lista de símbolos classificados como tipo estado, para cada termo:

5.1.1 – Para cada impacto. 5.1.1.1 – Tentar identificar a importância relativa do termo para a ontologia.

Essa estratégia é similar a utilização de questões de competência proposta por Gruninger (1995). Essas questões são obtidas através do refraseamento dos impactos de cada símbolo em perguntas iniciadas por quando, onde o que, quem , por que e como.

5..1.1.2 - Checar se existem indicativos de negação no vocabulário mínimo que relacionem duas ou mais classes. Verificar se essas classes possuem um relacionamento do tipo disjunto (exemplo: macho e fêmea).

5.1.1.2.1 – Se verdadeiro, adicionar o disjoint a lista de axiomas 5.1.1.3 - Checar se é possível criar uma partição de valor.

5.1.1.3.1 – Criar uma classe pai para a partição 5.1.1.3.2 - Fazer com que as classes participantes da partição sejam

disjuntas entre si. 5.1.2 – Caso o termo seja central a ontologia, classifique-o como classe (C). 5.1.3 – Caso contrario (o temo não é central para a ontologia), classifique-o como

propriedade (R).

5.1.4 – Verificar consistência.


A seguir vamos elaborar o processo de mapeamento de acordo com o

preconizado na Figura 5.3.

1 – Listar os termos alfabeticamente de acordo com seu tipo (verbo, objeto, sujeito ou estado)

TABELA 5.12 – TERMOS DO LEL LISTADOS SEGUNDO O SEU TIPO

Verbo Sujeito Objeto Estado alterar participante

cadastrar cliente

cadastrar comissão

cadastrar comitê

cadastrar parceiros

consultar eventos em aberto

consultar eventos fechados

consultar participante

distribuir recursos

efetuar inscrição

efetuar pagamento

elaborar programação

emitir certificados

emitir crachás

enviar material

enviar palestra

enviar requisição

enviar trabalho

excluir participante

fornecer recursos

pagar fornecedor

receber pagamento

receber recursos

selecionar ministrante

selecionar palestrante,

solicitar inscrição

Apresentador

Cliente

Cliente inscrito

Comissão

Comitê

Fornecedor

Ministrante

Ouvinte

Palestrante

Participante

Patrocinador

Secretária

Certificado

Crachá

Evento

Inscrição

Material

Pagamento

Palestra

Programação

Recurso

Trabalho

Aberto Fechado

2 – Fazer três listas: Propriedades, classes e axiomas. Na lista de classes cada entrada terá um nome, descrição (linguagem natural) e uma lista contendo zero ou mais restrições (função que relaciona a classe em questão a outras, de maneira não-taxonômica). As entradas na lista de axiomas terão nomes (labels) somente.

Propriedade Classe Axioma


3 – Utilizando a lista de símbolos do léxico classificados como sujeito ou objeto, para cada termo:

3.1 – Adicionar uma nova classe a lista de classes. O nome da classe é o símbolo do léxico propriamente dito. A descrição da classe é a noção do termo.

3.1.1 – para cada impacto, 3.1.1.1 – checar se já não faz parte da lista de propriedades da ontologia 3.1.1.2 - Caso não faça parte da lista (a propriedade ainda não existe),

adicionar uma nova propriedade na lista (de propriedades). O nome da propriedade deve ser baseado no verbo utilizado para descrever o impacto.

3.1.1.2.1 – verificar consistências 3.1.1.3 – Na lista de classes, adicionar uma nova restrição para a classe em

questão. A restrição é formada pela classe + a propriedade (definida em 3.1.1.1) + a classe relacionada (essa classe é o objeto direto/indireto do verbo utilizado no impacto do símbolo do léxico. Usualmente é um termo do próprio léxico e aparece sublinhado)

3.1.1.4 – Checar se existem indicativos de negação no vocabulário mínimo que relacionem duas ou mais classes. Verificar se essas classes possuem um relacionamento do tipo disjuntos(exemplo: macho e fêmea).

3.1.1.4.1 – Se verdadeiro, adicionar o disjoint a lista de axiomas. 3.2 – Verificar consistência

TABELA 5.13 – MAPEAMENTO REALIZADO

Propriedades é-enviado é-selecionado é-apresentado é-alterado é-consultado é-inscrito é-elaborado é-enviado é-emitido é-fornecido é-pago é-solicitado é-excluído é-distribuído

Axioma Trabalho pode ser: full, short, poster Classes - Apresentador

Descrição: Cliente inscrito para apresentar trabalho - Trabalho Descrição: AArrttiiggooss aa sseerreemm aapprreesseennttaaddooss eemm uumm eevveennttoo - comitê Descrição: GGrruuppoo ddee ppeessssooaass sseelleecciioonnaaddaass ppaarraa sseelleecciioonnaarr ooss ttrraabbaallhhooss aapprreesseennttaaddooss nnoo eevveennttoo

- participante: Descrição: PP eessssooaa qquuee ppaarrttiicc iippaa ddee uumm eevveenntt oo ccoommoo:: oouuvviinnttee,, aapprreesseennttaaddoorr,,


ppaalleessttrraannttee,, mmiinniissttrraannttee - evento: Descrição: CCoonnffeerrêênncciiaa oouu WWoorrkksshhoopp aa sseerr ggeerreenncciiaaddoo ppeellaa eemmpprreessaa.. CCaaddaa eevveennttoo ppoossssuuii uumm ppeerrííooddoo ddee rreeaalliizzaaççããoo.. - cliente_inscrito Descrição: PP eessssooaa qquuee ssoolliicc iittoouu oo ccaaddaassttrroo ee ffooii aapprroovvaaddaa,, rreecceebbeennddoo oo sseeuu llooggiinn ee sseennhhaa - programação: Descrição: CCrroonnooggrraammaa aa sseerr ccuummpprriiddoo ddoo eevveennttoo CCoonntteemm aass ppaalleessttrraass,, ttrraabbaallhhooss ee ccuurrssooss aa sseerreemm aapprreesseennttaaddooss nnoo eevveennttoo - comissão Descrição: GGrruuppoo ddee ppeessssooaass sseelleecciioonnaaddaass ppaarraa ggeerreenncciiaarr oo eevveennttoo.. - ministrante Descrição: Cliente inscrito para ministrar curso - material

Descrição: OO mmaattee rr iiaa ll rree ffeerreennttee aaoo ccuurrssoo aa sseerr mmiinn iisstt rraaddoo ee mm uumm eevveennttoo - requisição

Descrição: Documento que contem referencias aos recursos materiais necessários para realizar a tarefa - palestrante Descrição: Cliente inscrito para ministrar palestra -palestra

Descrição: Slides referentes a um assunto a ser apresentado no evento - crachá

Descrição: IIddeenntt iiffiiccaaççããoo ddoo ppaa rrtt iicc iippaannttee ddoo eevveennttoo - certificado

Descrição: CCoo mmpprroovvaannttee ddee ppaarr tt iicc iippaaççããoo ddoo eevveennttoo - patrocinador Descrição: EEmmpprreessaa qquuee ffoorrnneecceemm rreeccuurrssooss ffiinnaanncceeiirrooss ppaarraa aa rreeaalliizzaaççããoo ddoo eevveennttoo - recursos

Descrição: São materiais necessários para a realização e elaboração do evento. Podem ser: financeiro, humano e material - pagamento

Descrição Comprovante de quitação com o evento - ouvinte Descrição: Cliente inscrito para assistir aos cursos, palestras e apresentações do evento


- cliente

Descrição: PPeessssooaa qquuee aa iinnddaa nnããoo ssoo lliicc iittoouu oo ccaaddaasstt rroo,, aappeennaass cc lliieennttee ee mm ppootteenncc iiaa ll - inscrição

Descrição IIddeenntt iiffiiccaaççããoo ddee uumm cc lliieennttee qquuaannddoo ddee sseejjaa ffaazzeerr ss eeuu ccaaddaass ttrroo - secretária Descrição: PP eessssooaa qquuee aauuxxiilliiaa nnoo ggeerreenncciiaammeennttoo ddoo eevveennttoo - fornecedor Descrição: EEmmpprreessaa qquuee ffoorrnneeccee rreeccuurrssooss ((mmaatteerriiaaiiss oouu hhuummaannooss)) ppaarraa aa rreeaalliizzaaççããoo ddoo eevveennttoo

4 – Utilizando a lista de símbolos classificados como tipo verbo, para cada termo: 4.1.1 – Checar se já faz parte da lista de propriedades da ontologia.

4.1.1.1 – Caso não faça parte da lista (a propriedade não existe), adicionar uma nova propriedade a lista (de propriedades). O nome da propriedade é o símbolo do léxico propriamente dito.

4.1.1.1.1 - Verificar consistência

Todos os verbos foram mapeados.

5 – Utilizando a lista de símbolos classificados como tipo estado, para cada termo: 5.1.1 – Para cada impacto.

5.1.1.1 – Tentar identificar a importância relativa do termo para a ontologia. Essa estratégia é similar a utilização de questões de competência proposta por Gruninger. Essas questões são obtidas através do refraseamento dos impactos de cada símbolo em perguntas iniciadas por quando, onde o que, quem , por que e como.

5..1.1.2 - Checar se existem indicativos de negação no vocabulário mínimo que relacionem duas ou mais classes. Verificar se essas classes possuem um relacionamento do tipo disjunto (exemplo: macho e fêmea). 5.1.1.2.1 – Se verdadeiro, adicionar o disjoint a lista de axiomas

5.1.1.3 - Checar se é possível criar uma partição de valor. 5.1.1.3.1 – Criar uma classe pai para a partição 5.1.1.3.2 - Fazer com que as classes participantes da partição sejam

disjuntas entre si. 5.1.2 – Caso o termo seja central a ontologia, classifique-o como classe (C). 5.1.3 – Caso contrario (o temo não é central para a ontologia), classifique-o como

propriedade (R). 5.1.4 – Verificar consistência.

Seguindo os passos acima criamos duas novas classes referentes ao estado de

aberto e fechado, com restrição de disjunção entre elas.


Foi criada uma classe de partição de valor chamada: tipo_evento, onde possui

referencia as outras classes de aberto e fechado.

Assim, ficou conforme demonstra a figura 5.4.

FIGURA 5.4 – MAPEAMENTO DOS SÍMBOLOS DO TIPO ESTADO

A última etapa do processo de construção de ontologias é a construção de uma

hierarquia de classes, onde identificamos conceitos que possam estar relacionados

hierarquicamente.

No topo da ontologia fica o termo mais genérico, e nas suas folhas os mais

específicos.

Assim, baseado nesta premissa, faremos os seguintes passos:

6 – Quando todos os termos tiverem sido adicionados a ontologia 6.1 – Checar se existem conjuntos de classes que podem compartilhar restrições

idênticas ou muito similares. 6.1.1 – para cada conjunto de classes idenfificado, construir uma lista de classes separada. 6.1.2 – buscar na ontologia outras classes que façam referencia a todos os membros desta lista 6.1.3 – construir uma hierarquia de classes em que todos os membros da lista de classes sejam uma subclasse da classe encontrada em 6.1.2 6.1.4 – verificar consistência.

Foram identificadas as seguintes listas:

Classes Aberto Definição: são os eventos que possuem o período de realização maior ou igual do que a data atual subClasseOf: tipo-evento Fechado Definição:são os eventos que possuem o período de realização menor do que a data atual subClasseOf: tipo-evento Tipo-Evento Definição: conjunto dos estados possíveis em que o evento pode estar no momento.Partição de valor.


FIGURA 5.5 – ESTRUTURA HIERÁRQUICA DA ONTOLOGIA EVENTOS

55..88 GGee rraaççããoo ddee AArrqquuiivvooss ppaa rraa EExxppoo rrttaaççããoo

Atualmente busca-se de um modo geral uma interoperabilidade entre

ferramentas de desenvolvimento que nem sempre é possível de se obter.

A exportação de documentos no padrão XML permite que se obtenha esta

interoperabilidade, mesmo que de forma simples, porém eficiente. Uma vez que tenhamos

o documento XML gerado e o padrão a ser obedecido por ele (seja através de uma DTD

ou de um XML Schema) podemos garantir a padronização e a leitura do mesmo.

Assim, através do padrão estabelecido no Capitulo 4 através d o s XML

Schemas, foram gerados documentos prontos para exportação.

Parceiros - fornecedor - patrocidador Cliente - cliente inscrito - cliente - participante (ouvinte, palestrante, apresentador, ministrante) Recursos -materiais ou humanos -financeiros Material_evento -palestra -curso -apresentação - requisição Grupo_trabalho - secretária - comitê - comissão Objetos_evento - crachá - certificado - programação


Estes documentos na sua íntegra estão no Anexo C, porém seguem alguns

trechos do mesmo:

Figura 5.6 – Trecho do Arquivo do LEL dos Símbolos em XML

Figura 5.7 – Trecho do Arquivo do LEL dos Cenários em XML

... <Projeto> <id_projeto>1 <dominio>comunicação <nome_projeto>Eventos <descricao>Controle de Eventos Científicos <LEL> <id_simbolo>1</id_simbolo> <nome_simbolo>fechado</nome_simbolo> <categoria>estado</categoria> <sinonimos> <alias> fechados</alias> ....

... <Projeto> <id_projeto>1 <dominio>comunicação <nome_projeto>Eventos <descricao>Controle de Eventos Científicos <cenarios> <Tipo_mdsodi> paralelo</Tipo_mdsodi"> <cenarioid>1</cenarioid> <titulo>distribuir recursos</titulo> <objetivo>distribuir recursos humanos, financeiros e materiais para o evento</objetivo>

...


Figura 5.8 – Trecho do Arquivo de Aspectos XML

Figura 5.9 – Trecho do Arquivo de Ontologias XML

... <Aspectos> <nome>validar situação</nome> <origem>RO</origem> <descricao>validar situação do cliente inscrito</escricao> ...

... <ontologias> <classe> <nome>comitê</nome> <descricao>Grupo de pessoas que avaliam os trabalhos para apresentação no evento</descricao> <restricao></restricao>

...



Neste capítulo realizamos o estudo de caso referente à abordagem proposta.

Ficou claro, a partir da análise efetuada, que a abordagem DAORE permite um tratamento

diferenciado para os requisitos funcionais, não funcionais e organizacionais. Além de

incorporar a identificação dos aspectos candidatos (ponto chave em Early Aspects).

A identificação dos aspectos candidatos facilita o trabalho do engenheiro de

requisitos, pois ele precisaria apenas refinar estes aspectos aceitando-os ou rejeitando-os

de acordo com suas prioridades.

Um outro ponto bem interessante é a exportação do arquivo em XML baseado

no Schema XML do LEL, ontologias e casos de uso e aspectos. Esta especificação

permite a interoperabilidade entre ferramentas, pois o desenvolvedor pode ter a

flexibilidade de escolha da ferramenta mais apropriada ao seu uso. Em um ambiente

distribuído de desenvolvimento, esta flexibilidade é fundamental, pois a equipe de

desenvolvimento não está presa a uma ferramenta padrão.

A autora acredita que a geração de um arquivo XML dos casos de uso seguindo

a MDSODI é um facilitador pois mesmo que não possa construir graficamente este recurso

permite a definição dos principais cenários do sistema e de seus atores seguindo a

metodologia MDSODI. Sendo um recurso poderoso e aliado na especificação do domínio

do sistema.

Assim, a abordagem DAORE provou que além de facilitar a identificação dos

aspectos candidatos, permite que sejam definidos parâmetros fundamentais para que se

possa atingir a próxima etapa do desenvolvimento, com a elaboração dos casos de uso.

6. A Ferramenta Requisite e a Abordagem DAORE 158

CAPÍTULO

66

A FERRAMENTA REQUISITE E A ABORDAGEM DAORE

Termos consciência de que somos ignorantes é um grande passo rumo ao saber. Disraeli

EEss ttee ccaappíí ttuulloo aapprreesseennttaa uummaa aannáálliissee ddaa ffeerrrraammeennttaa RReeqquuiiss iitt ee eemm ssuuaa

pprriimmeeiirraa vveerrssããoo ee aa vveerrssããoo aattuuaa ll,, bbaasseeaaddaa nnaa eexxppeerr iimmeennttaaççããoo

eeffeettuuaaddaa.. ÉÉ rreeaalliizzaaddoo uummaa aannáálliissee ddoo iimmppaacc ttoo qquuee eessssaa mmuuddaannççaa iirráá

pprroovvooccaarr nnoo pprroojjeettoo DDiiSSEENN,, sseeuuss pprrooss ee ccoonnttrraass .. PPoorr ffiimm,, aavvaalliiaammooss

ssee aass mmuuddaannççaass ssããoo nneecceessssáárriiaass ppaarraa oo ffuuttuurroo ddoo pprroojjeettoo DDiiSSEENN..

66..11 SSiittuuaaççããoo AAttuuaall

A ferramenta Requisite desenvolvida em Java no aplicativo NetBeans, possui

algumas limitações referentes a orientação a aspectos, mesmo porque, na sua concepção

não havia referencia na literatura sobre o assunto.

Foi desenvolvida usando a orientação a objetos e, como já foi visto no capítulo

2, a orientação a objetos não contempla de forma eficiente a identificação e composição

das propriedades transversais de um projeto de software.

Deste modo, algumas mudanças são necessárias para que se pudesse dispor de

algumas facilidades e contribuições da abordagem DAORE, como: ontologias, definições

dos requisitos não funcionais e suas operacionalizações, definição dos requisitos

organizacionais, importação através de um padrão pré-definido destes dados e,


principalmente, a identificação dos aspectos candidatos em um projeto a ser desenvolvido

no ambiente DiSEN.

As mudanças seriam bastante significativas justificando, inclusive, em uma

nova versão, como no caso da alteração efetuada na ferramenta OORNF.

O trabalho de Wiese (2006) aborda a questão de interoperabilidade entre as

ferramentas de desenvolvimento, realizando um trabalho de transformação do modelo de

casos de uso, entre as ferramentas: Poseidon1, Enterprise Architect2 e a Requisite. Seu

trabalho não seria alterado, uma vez que não estamos tratando dos casos de uso, mas sim

dos símbolos do LEL, seus cenários e aspectos relacionados.

A seguir veremos como está a ferramenta Requisite após a alteração efetuada

por Wiese (2006) e ainda sem as alterações de acordo com a DAORE.

6.1.1 – O Menu Principal da Requisite

Seu Menu Principal apresenta as opções verificadas na figura 6.1 e na Opção

File podemos observar que possui um sub-menu, que oferece as opções de:

· New – Especifica um novo projeto, por isso, talvez a opção possa ser

renomeada para Project, ao invés de File.

· Open Recent – especifica os projetos recentes que foram abertos. Esta

opção não pode ser verificada pois não está operacional.

· Open – esta opção só funciona se o usuário abrir um novo projeto,

fecha-lo e logo depois tentar abrir, sem fechar a ferramenta, senão ela

não consegue abrir o projeto.

· Save – salva um projeto aberto que já foi salvo.

· Save as – salvar como, para um projeto aberto esta opção permite a

escolha do nome do projeto e a pasta de localização.

· Open from DiSEN – busca um arquivo .XMI – não pode ser testado,

uma vez que não possuía um arquivo XMI do projeto DiSEN (foco do

trabalho de Wiese).

1 Disponível para download em: http://www.gentleware.com/. 2 Disponível para download em: http://www.sparxsystems.com/


· Save to DiSEN – salva um arquivo no formato .XMI. Ele cria o arquivo

especificado, porém não pode ser testado (foco do trabalho de Wiese).

· Close – Fecha o projeto aberto.

· Exit – Sair da ferramenta.

FIGURA 6.1 – MENU PRINCIPAL DA FERRAMENTA REQUISITE.

As opções Edit, Diagrams e Windows, não estão operacionais sem instanciação

de projeto ou a criação de um novo. A opção Help oferece apenas uma tela sobre

informações gerais do sistema.

Os botões localizados no lado esquerdo e acima são botões rápidos para acessar

determinadas tarefas, os botões e permitem que se selecionados, ao incluirmos

uma associação entre os casos de uso, estas serão identificadas com o estereotipo

<<exclusive>> ou <<include>>.

A figura 6.2 apresenta o NetBeans3 e a ferramenta Requisite e seu código a ser

analisado.

3 Disponível em: http://www.netbeans.org/ . Último acesso em: 22/11/06.


FIGURA 6.2 – NETBEANS E A FERRAMENTA REQUISITE.

66..22 IImmpplleemmeennttaa nnddoo aa DDAAOORREE

Cada vez mais os projetos desenvolvidos requisitam um maior uso de recursos

e até mesmo novas técnicas que permitam que acompanhem e usem a evolução natural da

tecnologia.

Isto se aplica também aos processos de desenvolvimento. Deste modo,

podemos prever que a inclusão de aspectos candidatos nos projetos desenvolvidos no

ambiente DiSEN permitem acrescentar novas características que podem ser tratadas desde

o inicio do desenvolvimento.

Assim, podemos afirmar que futuros projetos se beneficiarão com a

implantação das características providas pela DAORE.

66..22..11 –– PPrroojjeettoo DDiiSSEENN

O projeto DiSEN possui como objetivo principal prover um ambiente de

desenvolvimento de software distribuído. Isto implica no uso integrado de várias

ferramentas de desenvolvimento, sejam elas na forma de plugins ou stand-alone.

Assim, a exportação de dados, sejam eles no formato XML ou através de

transformações de modelos, como no trabalho de Wiese (2006) para casos de uso, devem

existir no projeto.

Este uso se explica pelo fato de que nem sempre há a possibilidade de todos

utilizarem a mesma ferramenta para a mesma fase, mesmo porque, deve existir uma

customização ou adaptação para as ferramentas utilizadas pela equipe de desenvolvimento.


Deste modo, o projeto DiSEN pode ser beneficiado com a implementação na

fase de requisitos de uma abordagem que permita e padronize os documentos a serem

gerados, além de possibilitar a identificação dos aspectos candidatos do projeto.

66..22..22 –– AA NNoovvaa FFeerrrraammee nnttaa RRee qquuiissiittee

A modelagem dos diagramas referentes à n ova versão da Requisite foram

elaborados utilizando o Borland Together Architect4.

Inicialmente, modelamos o diagrama de casos de uso, figuras 6.3 e 6.4.

FIGURA 6.3 – BORLAND TOGETHER ARCHITECT E A REQUISITE

4 Disponível em: http://www.borland.com/br/products/together/index.html . Ultimo acesso em: 22/11/06.


Exportar XML

Construir hierarquia

Construir use case

Gerar Ontologias

gerar cenarios

Gerar Aspectos

Construir Cenarios

Engenheiro de Requisitos

Cosntruir RO

Gerar ator

Gerar recursos

Construir RNF

Criar Projeto

Construir Lexico<<include>>

<<include>>

<<include>>

<<extend>>

FIGURA 6.4 – DIAGRAMA DE CASOS DE USO DA NOVA REQUISITE

Observando a figura 6.4 podemos concluir que a nova versão da ferramenta

Requisite possui algumas funcionalidades que não existiam na versão anterior (para uma

comparação entre os casos de uso, verifique o capítulo 2, onde está detalhada a ferramenta

requisite). Estas funcionalidades, previstas na abordagem DAORE permitem que a

ferramenta construa requisitos não funcionais, requisitos organizacionais, gere os

elementos dos cenários a partir dos símbolos do LEL, gere aspectos e construa a ontologia

do projeto.

Assim, podemos verificar que além das funcionalidades já existentes na versão

anterior teremos:

a) Construir RNF – permite que se crie, modifique, consulte e remova os

requisitos não funcionais primários e secundários, bem como as suas estratégias de

satisfação;

b) Construir RO – permite que se crie, modifique, consulte e remova os

requisitos organizacionais ligados ao projeto;

c) Exportar XML – permite que se exporte documentos no formato XML a

partir dos XML Schemas definidos pela DAORE para símbolos do LEL, cenários,

ontologias e aspectos candidatos;


d) Gerar Aspectos – permite que se possa gerar e atualizar os aspectos

candidatos do projeto a partir dos RNF definidos e das diretrizes propostas;

e) Gerar ontologias – permite que se possa criar e atualizar as ontologias a

partir dos símbolos do LEL definidos para o projeto; e

f) Construir hierarquia – permite que se possa criar e atualizar as hierarquias

para as classes de ontologias definidas para o projeto.

A partir do diagrama de casos de uso da ferramenta Requisite elaboramos o

diagrama de classes de acordo com a figura 6.5.


FIGURA 6.5 – DIAGRAMA DE CLASSES PROPOSTO DA NOVA VERSÃO DA REQUISITE


O diagrama de classes apresentado na figura 6.5 apresenta as seguintes

características adicionais:

· Identificação do símbolo do LEL, como subject, verb, object ou

state;

· Associação do Behavioral Response com requisitos não funcionais,

funcionais e organizacionais, além de poder ser introduzido

instruções OCL;

· Associação dos cenários ao símbolo do LEL identificado como

verbo;

· Associação dos símbolos do LEL com os termos da ontologia;

· Geração de aspectos candidatos automaticamente a partir dos RNF

incluídos no projeto através do Behavioral Response; e

· Exportação de arquivos no padrão XML através de XML Schemas

definidos.

Deste modo, algumas mudanças nas interfaces foram efetuadas na ferramenta

Requisite para que possa se adequar a DAORE.

Primeiramente na figura 6.6 apresentamos uma tela inicial que é a entrada do

Requisite, sendo necessário digitar a senha de acesso ao sistema.

FIGURA 6.6 – NOVA TELA DE ACESSO AO REQUISITE.

O Menu Principal foi alterado de forma a exibir opções abordadas na

abordagem DAORE, como podemos observar na figura 6.7.


FIGURA 6.7 – NOVO MENU PRINCIPAL DA FERRAMENTA REQUISITE.

Podemos observar que a figura 6.7 apresenta como opções principais: Project,

LEL, Restrictions, Use Case, Ontology e Help. A opção Project é o antigo File e apresenta

o sub-Menu da figura 6.8

FIGURA 6.8 – SUB-MENU DE PROJECT.


Agora, como estamos nos conectando com o banco POSTGRESQL, algumas

opções foram excluídas, para a incorporação de outras. Assim, a opção project passou a

ter:

· NEW – onde podemos criar novos projetos, atualiza- los e selecionar o projeto que

desejamos trabalhar. Apresenta a interface da figura 6.9;

FIGURA 6.9 – NEW - PROJECT.

Como podemos observar na figura 6.9, aparece um hint no campo Project ID,

indicando a ação que deve ser realizada. A intenção é de que tenhamos um pequeno help

de ajuda ao usuário. Assim, como neste campo, todos os campos inseridos tem essa

característica, bem como os botões inseridos.

· XML FILES - onde podemos gerar o arquivo XML de acordo com os XML Schemas

criados para o LEL, Cenários, Aspectos e Ontologias;

· Aspects –Permite que se gere os aspectos, atualize e gere os conflitos do projeto

selecionado;

· Exit – Sair da ferramenta.

A opção do Menu Principal LEL, apresenta as opções de acordo com a figura

6.10.


FIGURA 6.10 – SUB-MENU DA OPÇÃO LEL

Uma das maiores mudanças efetuadas na ferramenta diz respeito a tela

principal do LEL (a opção do sub-menu New/Update). Agora, podemos inserir a

característica principal do léxico, ou seja, qual é o seu tipo. A partir daí podemos realizar

uma série de procedimentos através da ferramenta de forma automática, como: geração de

atores, recursos e cenários, o que facilita o processo de construção do LEL.

Esta tela está de acordo com a interface da figura 6.11.


FIGURA 6.11 – NEW/UPDATE LEL

Assim, em cenários poderíamos ter especificado o tipo MDSODI, conforme na

ferramenta CALEL.

No Menu principal Restrictions podemos editar os RNF e RO. Estes seriam

inseridos em cenários, conforme a CALEL.

No Menu Principal Use Case seria incluído as opções do Wiese (de importação

e exportação do modelo XMI) e a elaboração dos diagramas de casos de uso, de acordo

com a figura 6.12.


FIGURA 6.12 – SUB-MENU USE CASE

Na seqüência, há a geração de ontologias conforme foi elaborado com a

CALEL.

As alterações efetuadas foram realizadas utilizando o NetBeans, conforme a

versão alterada por Wiese. A escolha do POSTGRESQL como banco de dados para a

persistência está de acordo com o que está sendo feito no projeto DISEN.

66..22..33 –– AAnnáá lliissee ddoo IImmppaaccttoo ddaass MMuuddaa nnççaass

As mudanças sugeridas na ferramenta Requisite permitem que a abordagem

DAORE seja incluída no seu processo sem afetar o trabalho que já estava sendo realizado.

Na verdade, houve um acréscimo de informações a serem adicionadas.

Estas informações dizem respeito às funcionalidades do projeto a ser

desenvolvido, logo, adicionam uma maior clareza na definição dos requisitos a serem

mapeados.


Porém, precisa-se analisar o impacto de uma mudança efetuada na ferramenta

Requisite e no projeto DiSEN a fim de se avaliar se a mudança não será uma quebra de

paradigma.

Para isso precisamos identificar pontos a serem analisados e comparados com

as diferentes versões da Requisite, a anterior e a atual. Deste modo, a fim de definir

parâmetros de comparação para avaliar as duas ferramentas, iremos utilizar a NBR 13596

- Tecnologia de Informação: Avaliação de Produto de Software (ISO 9126) e utilizada no

capítulo 2 para realizar a comparação entre as abordagens de desenvolvimento.

Ao levarmos em conta o Requisite na sua versão original e o novo requisite,

podemos mapear uma tabela baseado no estudo de caso realizado entre ambas, este

mapeamento está descrito na tabela 6.1.

TABELA 6.1 – MAPEAMENTO ENTRE AS VERSÕES DA REQUISITE

Característica Sub-característica Requisite Original Novo Requisite

Adequação

- Faltava persistência - Identificação dos RNF e RO

Atendida

Acurácia Faltava identificação dos termos do LEL

Atendida

Interoperabilidade

A partir do trabalho de Wiese (2006) possui exportação e importação de arquivos XMI para casos de uso

Foi acrescida de exportação de arquivos XML seguindo um padrão definido no XML Schema

Conformidade

Faltava identificar os símbolos do LEL

De acordo com as especificações de Leite (1997) para o LEL

FUNCIONALIDADE

Segurança de acesso

Não implementado Através de identificação por senha

Maturidade Não aplicável Tolerância a falhas

CONFIABILIDADE

Recuperabilidade

Não implementado Aplicado no banco de dados definido

Inteligibilidade Apreensibilidade USABILIDADE Operacionalidade

Dificultada pela ausência de help

Help de auxilio disponível (hint)

EFICIÊNCIA Comportamento em relação ao

Bom tempo de resposta entre as

Bom tempo de resposta entre as


tempo Comportamento em relação aos recursos

operações e recursos utilizados

operações e recursos utilizados (Banco de dados)

Continuação da Tabela 6.1 Característica Sub-característica Requisite Original Novo Requisite

Adaptabilidade Capacidade para ser instalado

Desenvolvido em Java

Desenvolvido em Java

Capacidade para substituir

imediata imediata PORTABILIDADE

Analisabilidade circularidade circularidade Modificabilidade Java Java

MANUTENIBILIDADE Estabilidade

Não possui BD Através de mecanismos de BD

Ao observarmos a tabela 6.1 podemos verificar que a maturidade n ã o é

aplicada na análise, pois este item deve ser levado em conta quando do uso constante em

diversos projetos, com algum tempo de uso da ferramenta.

Algumas considerações são necessárias para as características e analise

efetuada na tabela 6.1:

· Adequação – em sua primeira versão a ferramenta Requisite não trata

dos requisitos não funcionais e organizacionais, sendo assim, deixa de

considerar aspectos importantes no projeto a ser desenvolvido, além

disso, a persistência não está sendo feita de forma adequada, conforme

foi visto no inicio deste capítulo. Com a modificação proposta, a nova

versão do Requisite irá suportar os RNF e organizacionais, além de

possuir integração com um banco de dados.

· Acurácia – A versão inicial da Requisite não faz identificação dos

termos definidos no LEL, dificultando a geração automática de alguns

elementos usados na especificação de cenários, como os atores e

recursos, além da própria identificação do cenário. Deste modo, a

geração de resultados satisfatórios ou corretos em relação aos termos do

LEL está comprometida.

· Interoperabilidade – com o trabalho de Wiese (2006) podemos exportar

e importar documentos XMI do projeto, porém apenas em relação aos

casos de uso especificados. Com a mudança proposta, a ferramenta


Requisite passaria a incluir a exportação de documentos XML em

padrões especificados através de XML Schema do LEL, cenários,

aspectos e ontologias.

· Conformidade – a ferramenta Requisite identifica os termos do LEL e a

partir destes, deveria facilitar a identificação e descrição dos cenários,

conforme previsto por Leite (1997). Porém, como não há a

identificação dos termos do LEL (o seu tipo) não podemos gerar de

forma automática os atores, recursos e os próprios cenários. Assim,

inicialmente não está de acordo com o que se prevê no LEL. Com a

mudança proposta, a identificação dos termos do LEL é o primeiro

passo para a geração automática dos cenários.

· Segurança de Acesso – Inicialmente a ferramenta Requisite está

implementada de forma não integrada ao ambiente DiSEN e sendo

assim precisa ter restrições de uso quanto ao projeto e usuários

qualificados. A nova versão da Requisite deve ser capaz de gerenciar e

tratar acessos indevidos, podendo ser através de senha de acesso.

· Tolerância a falhas e Recuperabilidade – geralmente este item está

ligado ao tratamento em relação aos seus dados, porém na primeira

versão da Requisite não há persistência e, deste modo, não existe

tratamento de rollback. A nova versão da Requisite deve possuir

tratamento com banco de dados, e o próprio mecanismo prevê

tratamentos de backup e recover dos mesmos (dependendo da versão do

banco de dados).

· Inteligibilidade, apreensibilidade e operacionalidade – a ausência de

help on line para determinadas tarefas é um ponto crucial para uma

aprendizagem mais rápida, além de facilitar a operacionalidade e

inteligibilidade de uma ferramenta. Em sua primeira versão, a Requisite

não possui help online, sendo mais uma característica a ser acrescentada

na nova versão.

· Comportamento em relação ao tempo e aos recursos – de um modo

geral a ferramenta, na primeira versão, apresenta um bom tempo de


resposta, sendo igualmente um fator a ser passado para a próxima

versão.

· Adaptabilidade e capacidade para ser instalada – desenvolvida em

Java, pode ser instalada no Windows ou Linux, não possuindo

restrições.

· Capacidade para substituir – Utilizando o LEL para auxiliar a definir

os cenários podemos substituir de forma imediata outra qualquer. Tanto

na versão anterior quanto na proposta, devemos manter os conceitos

básicos do LEL, a fim de possibilitar uma transição não traumática

entre ferramentas de desenvolvimento.

· Analisabilidade – a analisabilidade do projeto pode ser feita através dos

seus termos pelo princípio da circularidade.

· Modificabilidade – as duas versões podem ser alteradas utilizando

padrão java, porém sem termos um impacto maior no projeto DiSEN.

· Estabilidade – a primeira versão da ferramenta não possui

implementação em banco de dados e portanto, não possui a estabilidade

que um banco de dados pode oferecer. A nova versão possui integração

com um banco de dados, oferecendo uma estabilidade maior de suas

informações.

O impacto no projeto DiSEN seria principalmente no que diz respeito a

identificação dos aspectos candidatos do projeto a ser desenvolvido. Pois estes aspectos

irão influir nos passos definidos nos cenários.



Neste capítulo procurou-se identificar as principais mudanças a serem

elaboradas na ferramenta Requisite para que integrasse a abordagem DAORE e o impacto

destas mudanças no projeto DiSEN.

A preocupação maior foi de que o impacto fosse o menor possível, uma vez

que se refletiria no projeto DiSEN como um todo. Assim, foi verificado que as inclusões

necessárias para a execução das mudanças não afetou de forma desastrosa, pois a própria

ferramenta Requisite funciona ainda como uma ferramenta stand-alone em relação ao

projeto DiSEN, sendo um projeto futuro a implementação da mesma como um plug-in

(WIESE, 2006).

Assim, a possibilidade de gerar aspectos candidatos através do LEL do projeto

é altamente viável a partir das mudanças propostas.

Com isso, as próximas fases do processo de desenvolvimento podem usufruir

das facilidades oferecidas pela aplicação direta dos aspectos candidatos já elicitados,

podendo inclusive ser alvo de futuros estudos a extensão da abordagem para as outras

fases do desenvolvimento.

7.Conclusão 177

CAPÍTULO

77

CONCLUSÃO

Termos consciência de que somos ignorantes é um grande passo rumo ao saber. Disraeli

EEss ttee ccaappíí ttuulloo aapprreesseennttaa ddee mmaanneeiirraa ss iinnttéé tt iiccaa aass ccoonnttrriibbuuiiççõõeess ddaa

nnoossssaa aabboorrddaaggeemm.. DDeeppooiiss ,, ssuuggeerriimmooss aallgguunnss ttóóppiiccooss ppaarraa ttrraabbaallhhooss

ffuuttuurrooss ,, bbaasseeaannddoo--nnooss nnaass lliimmiittaaççõõeess ddaa aabboorrddaaggeemm pprrooppooss ttaa.. PPoorr

ffiimm,, aapprreesseennttaammooss nnoossssaass ccoonnss iiddeerraaççõõeess ffiinnaa iiss ..

77..11 CCoo nnttrriibbuuiiççõõeess

Henry Ford, o genial construtor de automóveis norte-americano ficou famoso

(entre outras coisas) por que aplicou um sistema de produção chamado 'em série' para a

fabricação de automóveis. Muitos pensam que Ford descobriu algo novo e revolucionário,

mas é fácil perceber que ele apenas implementou algo que a natureza vem fazendo desde

que a vida surgiu no planeta terra, milhares de milhões de anos atrás.

Neste processo, cada operário da fábrica somente se dedica a realizar uma

única tarefa, bem acabada, no menor tempo possível, dentro de uma chamada 'linha de

montagem'. Como resultado, a fábrica como um todo sai ganhando em tempo, qualidade e

preço dos seus produtos. Isto fez de Ford um dos homens mais ricos do seu tempo. Se cada

operário da fábrica construísse o carro completo desde o inicio até o final, demoraria

muitas vezes mais, teria uma qualidade provavelmente inferior, e seria enormemente caro.

7.Conclusão 178

Fazendo uma analogia com a engenharia de software tem-se com o conceito

(também antigo) do famoso “dividir para conquistar”. Com origens em técnicas de

construção de algoritmos, permitia que se tivesse a preocupação de lidar com um

problema por vez.

Assim, pode-se observar que a separação de propriedades não é uma técnica

recente, mesmo porque, ao construirmos um projeto de software aplicamos naturalmente a

separação de propriedades, independente da abordagem utilizada.

Kiczales et al. (1997) apresentou vários pontos em que a pesquisa na separação

de propriedades poderia avançar, entre eles estão:

(i) Como antecipar a modelagem de aspectos para as atividades de

análise e projeto; e

(ii) Como integrar a orientação a aspectos com métodos,

ferramentas e processos de desenvolvimento existentes.

Esta dissertação oferece contribuições nessas duas direções apontadas acima.

Primeiro, porque a abordagem proposta permite antecipar a identificação de aspectos

candidatos na fase de requisitos e segundo porque permite integrar esta identificação com

um processo ou técnica existente, como o LEL.

Além disso, aborda outras questões já existentes, como as de Cysneiros (2002)

e Breitman (2003) (2005), permitindo, inclusive, a exploração de uma nova faceta ligada à

ontologias para a Web Semântica, de acordo com a proposta apresentada por Breitman

(2005).

77..22 LLiimmiittaaççõõeess ee TTrraa bbaallhhooss FFuuttuurroo ss

Esta dissertação trata do desenvolvimento de software orientado a aspectos na

atividade de requisitos, mas sua principal limitação está condicionada a não análise de

como seria a transição para a fase de projeto e implementação do sistema.

Assim, podemos listar algumas perspectivas de trabalho futuras:

· Estender a abordagem DAORE para as outras fases do

desenvolvimento, especificando a transição entre as fases e seus

artefatos.

7.Conclusão 179

· Processo de Datamining na fase de requisitos com a utilização de

Ontologias.

· Implementar uma ferramenta integrada ao DiSEN (plug in) para suporte

a DAORE.

· Realização de mais estudos de caso nas abordagens existentes, a fim de

fornecer mais heurísticas e diretrizes para os desenvolvedores.

· Elaboração de análise sobre o impacto das adaptações realizadas em

relação a questões arquiteturais e em relação à iteratividade e

incrementalidade do Processo Unificado em relação a orientação a

aspectos.

· Construção de ferramenta que possa gerar automaticamente, a partir das

tabelas de composição e cenários do LEL, a perspectiva de

especificações de casos de uso e diagramas de interação com a presença

de aspectos que afetam esses artefatos; e

· Avaliação do LEL e sua possível integração com a Model Driven

Architecture - MDA (MDA, 2003) como proposta de m elhoria das

especificações do projeto e aumento de reuso dos componentes.

77..33 CCoo nnssiiddee rraaççõõeess FFiinnaaiiss

Conforme apresentado no Capítulo 4, o objetivo inicialmente proposto foi o de

estabelecer uma abordagem simples para possibilitar a identificação dos aspectos

candidatos na fase de requisitos do ciclo de desenvolvimento.

Este objetivo foi alcançado por meio da inserção dos fundamentos do

paradigma orientado a aspectos na integração do LEL, mas sem ocasionar tanto impacto

em como o processo é conduzido, já que as alterações concentram-se mais na

contextualização dos cenários no LEL.

Além disso, pelo fato das adaptações não se prenderem aos mecanismos de

uma linguagem orientada a aspectos específica e sim aos conceitos fundamentais do

paradigma orientado a aspectos, a abordagem DAORE oferece suporte tanto a uma

7.Conclusão 180

implementação orientada a aspectos (lidando com os aspectos candidatos) como a uma

implementação tradicional (cenários no LEL).

Outra característica positiva da abordagem DAORE é que as adaptações

seguem um raciocínio lógico a partir da especificação dos requisitos. Especificando-os

primeiramente e ao longo do desenvolvimento do processo e incluindo aspectos

relacionados à implementação de RNF e RO após a identificação dos símbolos existentes

nos RF.

A implementação dos aspectos através de tabelas de composição, permite

separar as preocupações transversais nos cenários aos quais ela se apresenta, garantindo

que estas preocupações aspectuais tenham uma definição clara de quando e como será

implementada.

Pelo fato de possibilitar a separação das propriedades transversais, os artefatos

que obtidos a partir da experimentação realizada possuem um melhor potencial de reuso,

manutenção e compreensão, quando comparados com aqueles que seriam obtidos

seguindo uma abordagem tradicional, na qual as propriedades transversais, normalmente,

ficariam espalhadas e misturadas nos artefatos.

Outros experimentos são interessantes a fim de avaliar e aprimorar a

abordagem proposta, pois este trabalho representa o primeiro passo para que seja utilizado

o LEL no processo de desenvolvimento de software orientado a aspectos.

77..44 TTrraa bbaa llhhooss SSuubbmmeettiiddooss

Durante a elaboração desta dissertação muitas idéias e soluções foram

apresentadas. Por conseqüência alguns trabalhos (papers) tomaram forma, de modo que

foi submetido a alguns eventos.

Deste modo, segue a lista de trabalhos e eventos submetidos e a submeter:

1. SOMET 06 - The 5th International Conference on Software Methodologies, Tools and Techniques - Québec, Canadá. Realizado no período de 25 a 27 de outubro de 2006. Título: Comparing Approaches in AORE through ISO/IEC 9126. Condição: Aceito.

2. RITA - Revista de Informática Teórica e Aplicada. Título: Comparing Approaches

in AORE through ISO/IEC 9126.

7.Conclusão 181

3. SBES - 21th Brazilian Symposium on Software Engineering – 2007. Título: AORE

in a Distributed Environment: The DAORE Approach

4. XXIII Conferência LatinoAmericana de Informática - 9-12 Octubre - San José - Costa Rica

Referencias Bibliográficas 182

Referências Bibliográficas

Só é útil o conhecimento que nos torna melhores. Sócrates

NNeess ttaa ppaarrttee aapprreesseennttaammooss aass rreeffeerrêênncciiaass bbiibblliiooggrrááff iiccaass ccoonnssuullttaaddaass ppaarraa aa

eellaabboorraaççããoo ddaa ddiisssseerrttaaççããoo..

AKSIT, M.; TEKINERDOGAN, B. and BERGMANS, L. The Six Concerns for Separation of Concerns, in Proceedings of ECOOP 2001 Workshop on Advanced Separation of Concerns, Budapest, Hungary, June 18-22, 2001.

AORE – Goals - overview. Disponível em: http://www.cs.toronto.edu/cser/aore.html. Acesso em 13/01/2006.

ARAUJO,J. et al. Aspect-Oriented Requirements with UML. Workshop on Aspect-Oriented Modelling with UML. 2002. April 22-26, Enschede, The Netherlands.

BAKKER, J. ; Tekinerdoğan, B. ; Aksit, M. ; Characterization of Early Aspects Approaches. presented at Workshop on Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design, held in conjunction with AOSD Conference, 2005. Vancouver, Canada.

BANIASSAD, E.; Clarke,S. Theme: An approach for aspect-oriented analysis and design, 26th International Conference on Software Engineering (ICSE), IEEE Press, Edinburgh, Scotland, Maio 2004.

BANIASSAD, E.; Clarke,S. Investigating the Use of Clues for Scaling Document-Level Concern Graphs, Early Aspects 2004: Aspect-Oriented Requirements Engineering and Architecture Design, workshop of the OOPSLA 2004, Vancouver, Canada, Outubro 2004.

BATISTA, S. M. Uma Ferramenta de Apoio à Definição de Requisitos da MDSODI no contexto do ambiente DiSEN. 2002. Dissertação de mestrado 83p – Departamento de Informática - Universidade Estadual de Maringá/Universidade Federal do Paraná. Maringá: 2003.

BERGMANS, L. and AKSIT, M. Composing Software from Multiple Concerns: A Model and Composition Anomalies, Multi Dimensional Separation of Concerns in Software Engineering Workshop, ICSE 2000, Limerick, Ireland, 2000.


BERGMANS, L.; AKSIT, M and TEKINERDOGAN, B. Aspect Composition Using Composition Filters, In Software Architectures and Component Technology: The State of the Art in Research and Practice, M. Aksit (Ed.), Kluwer Academic0 Publishers, pp. 357 - 382, October 2001. (ISBN 0-7923-7576-

BREITMAN, K.K., LEITE J.C.S.P, A Framework for Scenario Evolution. Proc. of the Third IEE inter. Conference on Req. Eng. IEEE Computer Society Press, Los Alamitos, CA, 1998, pp:214-221.

BREITMAN, K.K., LEITE, J.C.S.P., BERRY, D., M., Scenario Evolution: A Closer View on Relationships. ICRE 2000: 95-105. Meeting Date: 06/19/2000 - 06/23/2000 Schaumburg, IL, USA.

BREITMAN, K.K.; LEITE, J.C.S.P. Lexicon Based Ontology Construction. Lecture Notes in Computer Science 2940- Editors: Carlos Lucena, Alessandro Garcia, Alexander Romanovsky, et al. - ISBN: 3-540-21182-9 - Springer-Verlag Heidelberg, February 2004, pp.19-34.

BREITMAN, Karin. Web Semantica: A Internet do Futuro. Rio de Janeiro. LTC. 2005.

BRITO, J and Araújo ,A. Crosscutting Quality Attributes for Requirements Engineering, 14th International Conference on Software Engineering and Knowledge Engineering (SEKE 2002), ACM Press, Italy, July 2002.

BRITO, A.MOREIRA e J. ARAÚJO, A Requirements Model to Quality Attributes, “Workshop on Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design”, 1st International Conference on Aspect-Oriented Software Development (AOSD 2002), 22 - 26 de Abril de 2002, Holanda.

BRITO, I. ; MOREIRA, A.. Advanced Separation of Concerns for Requirements Engineering. VIII Jornadas de Ingeniería de Software y Bases de Datos (JISBD), Alicante, Spain, 12-14 Novembro 2003.

BRITO,I. and A. MOREIRA. Integrating the NFR framework in a RE model. Early Aspects 2004: Aspect-Oriented Requirements Engineering and Architecture Design, workshop of the 3rd International Conference on Aspect-Oriented Software Development, Lancaster, UK, 22- 26 Março 2004.

BOOCH, G.; RUMBAUGH, J . , JACOBSON, I . The Unified Modeling Language , Addison-Wesley,1999.

CHITCHYAN, Ruzanna et al. Survey of Aspect-Oriented Analysis and Design Approaches. Survey Lancaster University. May, 2005.

CHITCHYAN, Ruzanna; RASHID, A w a i s ; SAWYER, P e t e r . Comparing requirements engineering approaches for handling crosscuting concerns. Workshop on Requirements Engineering (held with CAiSE), Porto, Portugal, June 12-14, 2005.

CHUNG, L. et al. Non-Functional Requirements in Software Engineering, Kluwer Academic Publishing, 2000. 472pp. ISBN 0-7923-8666-3.

CLARKE, Siobhán; BANIASSAD, Elisa. Aspect-Oriented Analysis and Design – the theme approach. United States. AddisonWesley, March, 2005.


CONSTANTINIDES, C. ; HASSOUN, Y. Beyond objects: Improving the modularity of complex software. Workshop on Grand Challenges for Computing Research. Edinburgh, Scotland, November 24-26, 2002.

CYSNEIROS, L.M. Non-Functional Requeirements: From Elicitation to Conceptual Models– Tese de Doudorado. PUC_Rio – Feb 2001

DIJKSTRA, E. A Discipline of Programming. Prentice Hall, Englewood Cliffs, NJ, 1976.

ELRAD, T., FILMAN, R. and BADER, A. Aspect-Oriented Programming: Introduction, Communications of the ACM, v.44 n.10, p.29-32, Oct. 2001

ELRAD, T. et al. Discussing Aspects of AOP. Communications of the ACM, 44(10):33–38, October 2001.

FIGUEIREDO, E. et al. Assessing Aspect-Oriented Artifacts: Towards a Tool-Supported Quantitative Method. Workshop on Quantitative Approaches in OO Software Engineering (QAOOSE, held with ECOOP 2005), Glasgow, Scotland, July 2005

FILHO, T. L. Metodologia de Desenvolvimento de Sistemas , Axcel Books, Rio de Janeiro,2003.

FRANCO, A. P. ; LEITE, J. Uma Estratégia de Suporte à Engenharia de requisitos. MI Congresso da Sociedade Brasileira de Computação, Outubro 1992, pp. 200-213.

GANE, C.; SARSON,Trish. Structured Systems Analysis , New York, Improved System Technologies, 1977.

GRAVENA, J. P. Aspectos importantes de uma metodologia para desenvolvimento de software com objetos distribuídos. Trabalho de graduação – Departamento de informática – Universidade Estadual de Maringá. Maringá: 2000.

GRUNDY, J.C. Aspect-oriented Requirements Engineering for Component-based Software Systems, 1999 IEEE Symposium on Requirements Engineering, Limmerick, Ireland, 7-11 June, 1999, IEEE CS Press.

GRUBER, T. R.. A translation approach to portable ontology specifications. Knowledge Acquisition, 5:199--220, 1993.

GOSLING, J. et al. The Java Language Specification. Addison-Wesley, 2nd Edition, 2000.

HADAD, Graciela et. al. Construcción de Escenarios a partir del Léxico Extendido del Lenguage JAIIO'97, Buenos Aires, 1997, pp. 65-77.

Haumer, Peter ; POHL, Klaus; WEIDENHAUPT, Klaus. Requirements Elicitation and Validation with Real World Scenes. IEEE Trans. Software Eng. 24(12): 1036-1054 (1998)

HUZITA, E. H. M. Uma Metodologia para Desenvolvimento Baseada em Objetos Distribuídos Inteligentes. Projeto de Pesquisa. Universidade Estadual de Maringá, Departamento de Informática. 1999


IEEE. Qualities of a good software requirements specification (SRS) . Versão traduzida disponivel em: www.ieee.org e http://www.unoeste.br/fipp/estagio/arquivos/IEEE-Std-830-1998_traducao.pdf . Acesso em 13/01/2006.

ISO, International Standard ISO/IEC 9126: Software Engineering - Product Quality. Disponível em http://www.iso.org/. Acesso em 13/01/2006.

JACOBSON, I.; NG, P.W. Aspect-Oriented Software Development with Use Cases, Addison Wesley 2005.

JACOBSON, Ivar. Aspect composition at requirements-level. Blog de discursão sobre orientação a aspectos. Disponível em http://early-aspects.blogspot.com/. Acesso em 27/12/05.

JR, S. M. S. Concerns in a Requirements Model – A Small Case Study. In Proceedings of Early Aspects 2003: Aspect-Oriented Requirements Engineering and Architecture Design, Workshop, March 17, Boston, USA, 17 Mar. 2003.

KERSTEN, M. and MURPHY, G. Atlas: A Case Study in Building a Web-Based Learning Environment using Aspectoriented Programming. In OOPSLA’1999. 1999.

KICZALES, G. et al. An Overview of AspectJ. In J. L. Knudsen, editor, 15th European Conference on Object- Oriented Programming, volume 2072 of LNCS, pages 327– 353, Berlin, Heidelberg, and New York, Springer Verlag, 2001.

KERZNER,H. Project Management: A Systems Approach to Planning, Scheduling, and Controlling Publisher John Wiley and Sons, 2003.

LEITE J.C.S.P.; Franco, A.P.M. A Strategy for Conceptual Model Acquisition in Proceedings of the First IEEE International Symposium on Requirements Engineering, SanDiego, Ca, IEEE Computer Society Press, 1993 pp. 243-246

LEITE, J. C.S.P. Enhancing a Requirements Baseline with Scenarios. Requir. Eng. 2(4): 184-198 (1997)

LIEBERHERR, K. Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns. PWS Publishing Company, Boston, 1996.

LOUCOPOULOS, P. ; KARAKOSTAS, V . System Requirements Engineering, McGraw-Hill, 1995.

MAMANI, Nestor A. Integrando requisitos não funcionais aos requisitos baseados em ações concertas, Dissertação de mestrado, Departamento de informática, PUC-RIO, Maio, 1999.

MARTINEZ, E. N.; TORRES, P. L.; SALAVERT, I. R. . Goals and Quality Characteristics: Separating Concerns. Early Aspects 2004: Aspect-Oriented Requirements Engineering and Architecture Design Workshop, collocated to OOPSLA 2004, Monday, October 25, 2004, Vancouver, Canada (Accepted) - 2004

MCMENAMIN, S.; PALMER,J . F . Análise Essencial de Sistemas , Makron Books, São Paulo,1984.


MDA G u i d e . Disponível em: http://www.omg.org/docs/omg/03-06-01.pdf. Ultimo acesso em:04/11/06.

MILI, H. ; Elkharraz, A.; Mcheick, H.. Understanding Separation of Concerns. In Workshop on Early Aspects - Aspect Oriented Software Development (AOSD'04), pages 411{428, March 2004.

MOREIRA, A.; Araújo, J.; Brito, I. Crosscutting Quality Attributes for Requirements Engineering. Proceedings of the 14th International Conference on Software Engineering and Knowledge Engineering (SEKE), Ischia, Italy, ACM Press, pp. 167-174, Julho 2002.

MORO, C. F. Proposta de um Repositório de Metadados para Ambiente de Desenvolvimento de Software Distribuído. Maringá: DINUEM/ UFPR, 2002. Dissertação de Mestrado.

OSSHER, H. and TARR, P. Multi- Dimensional Separation of Concerns and the Hyperspace Approach. In Proceedings of the Symposium on Software Architectures and Component Technology: The State of the Art in Software Development. Kluwer, 2000.

PARNAS, D . On the Criteria to be Used in Decomposing Systems into Modules. Communications of the ACM, 15 (12), December 1972, pp. 1053- 1058.

PASCUTTI, M. C. D. Uma proposta de arquitetura de um ambiente de desenvolvimento de software distribuído baseada em agentes. Dissertação de mestrado – Programa de Pós-Graduação em Ciência da Computação, Instituto de Informática, Universidade Federal do Rio Grande do Sul. Porto Alegre: 2002

PEDRAS, M. E. V. Uma Ferramenta de Apoio ao Gerenciamento de Desenvolvimento de Software Distribuído. Maringá: DINUEM/ UFPR, 2002. Dissertação de Mestrado.

PRESSMAN, R. Software Engineering: a Practitioner’s Approach. 6th ed., McGraw-Hill, 2001.

RASHID, A. et al. Early Aspects: A Model for Aspect-Oriented Requirements Engineering. Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE), Essen, Germany, IEEE CS Press, pp. 199-202, Setembro 2002.

RASHID, A. ; MOREIRA, A .; ARAÚJO, J . Modularisation and Composition of Aspectual Requirements. Proceedings of the 2nd International Conference on Aspect-Oriented Software Development (AOSD), Boston, USA, ACM Press, pp. 11-20, Março 2003.

ROYCE, W. Software project management: a unified framework - 1998 - Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA

SANTANDER, Victor Francisco Araya . Integrando Modelagem Organizacional com Modelagem Funcional, Tese de Doutorado, CIn - UFPE, Recife, Dezembro. 2002.

SCOTT, Kendall. O Processo Unificado Explicado. Bookman,, Porto Alegre,2003

SILVA, L. et al.. Comparing Approaches in AORE through ISO/IEC 9126. The 5th International Conference on Software Methodologies, Tools and Techniques , Quebec – Canadá, 2006


SILVA, L. de P. Uma proposta de evolução em sistemas legados. Monografia - Especialização, Curso de Pós-Graduação em Sistemas de Informação Distribuídos, UNIOESTE, 2004.

SILVA, Lyrene; Leite, Julio C. Sampaio. Integração de características transversais durante a modelagem de requisitos. 19º Simposio Brasileiro de Engenharia de Software. Minas Gerais, 2005.

SHLAER, S.; MELLOR, S. Análise de Sistemas Orientada para Objetos, Makron Books, São Paulo,1990.

SOMMERVILLE, I. Software Engineering fourth edition, Addison-Wesley, 1992.

SOMMERVILLE, IAN; SAWYER, PETER; VILLER, STEPHEN, Viewpoints for Requirements Elicitation: A Practical Approach, Proceedings of the 3rd International Conference on Requirements Engineering: Putting Requirements Engineering to Practice, p.74-81, April 06-10, 1998

SOUZA, D. ; Wills, A.. Objects, Components and Frameworks with UML: The Catalysis Approach, USA: Addison-Wesley, (1995).

SOUZA, Georgia M. C. Uma Abordagem Direcionada a Casos de Uso para o Desenvolvimento de Software Orientado a Aspectos. Dissertação de Mestrado, UFPE, 2004.

SOUZA, Michel. Metadados. Disponível em: http://www.imasters.com.br/artigo/1569/bi/metadados/. Ultimo acesso em 23/10/06.

TARR, P. et al. N Degrees of Separation: Multidimensional Separation of Concerns. In Proceedings of the 21st International Conference on Software Engineering (ICSE'99), 107–119, May 1999. Los Angeles, California, United States.

TEKINERDOĞAN, Bed i r : ASAAM: Aspectual Software Architecture Analysis Method. WICSA 2004: 5-14

THEME. Conceitos Gerais sobre a Abordagem Theme e ferramenta Theme/Doc Disponível em: http://www.dsg.cs.tcd.ie/index.php .. Acesso em 23/01/06.

TORANZO, Marco A., Uma Proposta para Melhorar o Rastreamento de Requisitos de Software, Centro de Informática, Universidade Federal de Pernambuco, Tese de Doutorado, Dezembro, (2002).

TRAVASSOS, G. H. Introdução a Engenharia de Software Experimental. Relatório técnico. Programa de Engenharia de Sistemas e Computação. COPPE/UFRJ, 2002.

UML - Unified Modeling Language, version 2.0. The Object Management Group. Disponível em: http://www.uml.org/. Ultimo acesso: 26/09/2006.

XML SCHEMA. Disponível em: http://www.w3.org/XML/Schema ultimo acesso em 23/10/06.

YU, E . , Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering, Proceedings of IEEE International Symposium on Requirements Engineering - RE97, Jan, (1997), pp.226-235.


YU, Y . ; LEITE, J . ; MYLOPOULOS, J . From goals to aspects: discovering aspects from requirements goal models, Proceedings of the 12th IEEE International Requirements Engineering Conference (RE), pp.38 – 47. Kyoto, Japan, IEEE CS Press, Setembro 2004.

WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a objetos. São Paulo. Elsevier, 2004

W3C. Web-Ontology (WebOnt) Working Group . Documentos diversos sobre Ontologias. Disponível em: http://www.w3.org/2001/sw/WebOnt/. Ultimo acesso: 04/11/06.

Anexo A 189

ANEXO

AA

SCHEMAS XML GERADOS

AA sseegguuiirr aa pprreesseennttaammooss ooss SScchheemmaass XXMMLL ggee rraa ddooss ppaa rraa oo nnoossssoo

ttrraabbaa llhhoo.. PPrriimmeeiirraa mmeennttee aapprreesseennttaa mmooss aa vviissuuaa lliizzaaççããoo ggrrááffiiccaa ee

ddeeppoo iiss oo aa rrqquuiivvoo tteexxttoo..

OOss SScchheemmaass XXMMLL ffoo rraa mm eellaabboo rraa ddooss aattrraavvééss ddaa ffeerrrraa mmeennttaa

SSttyylluuss SSttuuddiioo 22..

Anexo A 190

AAssppeeccttoossLLEELL..xxssdd

?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="Aspectos"> <xsd:complexType> <xsd:sequence> <xsd:element name="Projeto"> <xsd:complexType> <xsd:attribute name="id" type="xsd:integer"/> <xsd:attribute name="nome" type="xsd:string"/> </xsd:complexType> </xsd:element> <xsd:element name="aspecto_candidato"> <xsd:complexType> <xsd:sequence> <xsd:element name="id" type="xsd:integer"/> <xsd:element name="nome" type="xsd:string"/> <xsd:element name="origem"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="RNF"/> <xsd:enumeration value="RF"/> <xsd:enumeration value="RO"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="descricao" type="xsd:string"/> <xsd:element name="cenariosafetados" maxOccurs="unbounded" minOccurs="1"> <xsd:complexType> <xsd:sequence>

Anexo A 191

<xsd:element name="cenarioid" type="xsd:integer"/> <xsd:element name="nome_cenario" type="xsd:string"/> <xsd:element name="condicao" type="xsd:string"/> <xsd:element name="regracomposicao"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="wrap"/> <xsd:enumeration value="overlap.after"/> <xsd:enumeration value="overlap.before"/> <xsd:enumeration value="override"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="pontojuncao" type="xsd:integer"/> <xsd:element name="informacoesadicionais" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>

LLEELLSSiimmbboollooss..xxssdd

Anexo A 192

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="Projeto"> <xsd:complexType> <xsd:sequence> <xsd:element name="id_projeto" type="xsd:integer"/> <xsd:element name="dominio" type="xsd:string"/> <xsd:element name="nome_projeto" type="xsd:string"/> <xsd:element name="descricao" type="xsd:string"/> <xsd:sequence> <xsd:element name="LEL"> <xsd:complexType> <xsd:sequence> <xsd:element name="id_simbolo" type="xsd:integer" minOccurs="1"/> <xsd:element name="nome_simbolo" type="xsd:string"/> <xsd:element name="categoria"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="sujeito"/> <xsd:enumeration value="verbo"/> <xsd:enumeration value="estado"/> <xsd:enumeration value="objeto"/>

Anexo A 193

</xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="sinonimos"> <xsd:complexType> <xsd:sequence> <xsd:element name="alias" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="nocoes"> <xsd:complexType> <xsd:sequence> <xsd:element name="id_nocao" type="xsd:integer"/> <xsd:element name="descricao_nocao" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="impactos"> <xsd:complexType> <xsd:sequence> <xsd:element name="id_impacto" type="xsd:integer"/> <xsd:element name="descricao_impacto" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>

Anexo A 194

LLEELLCCeennaarriiooss..xxssdd

<?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="Projeto"> <xsd:complexType> <xsd:sequence> <xsd:element name="id_projeto" type="xsd:integer"/> <xsd:element name="dominio" type="xsd:string"/> <xsd:element name="nome_projeto" type="xsd:string"/>

Anexo A 195

<xsd:element name="descricao" type="xsd:string"/> <xsd:element name="cenarios"> <xsd:complexType> <xsd:sequence> <xsd:element name="Tipo_mdsodi"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="sequencial"/> <xsd:enumeration value="paralelo"/> <xsd:enumeration value="distribuido"/> <xsd:enumeration value="paralelo_distribuido"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="cenarioid" type="xsd:integer"/> <xsd:element name="titulo" type="xsd:string"/> <xsd:element name="objetivo" type="xsd:string"/> <xsd:element name="contexto"> <xsd:complexType> <xsd:sequence> <xsd:element name="texto" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="atores"> <xsd:complexType> <xsd:sequence> <xsd:element name="nome" type="xsd:string"/> <xsd:element name="tipo_ator" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="recursos"> <xsd:complexType> <xsd:sequence> <xsd:element name="descricao" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="episodios"> <xsd:complexType> <xsd:sequence> <xsd:element name="texto" type="xsd:string"/> <xsd:element name="RNFEspecifico"> <xsd:complexType> <xsd:sequence> <xsd:element name="texto" type="xsd:string"/> <xsd:element name="estrategia" type="xsd:string"/> </xsd:sequence> </xsd:complexType>

Anexo A 196

</xsd:element> <xsd:element name="ExpressaoOCL"> <xsd:complexType> <xsd:sequence> <xsd:element name="texto" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Rorg"> <xsd:complexType> <xsd:sequence> <xsd:element name="texto" type="xsd:string"/> <xsd:element name="estrategia" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>

OOnnttoollooggiiaa..xxssdd

Anexo A 197

<?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="ontologias"> <xsd:complexType> <xsd:sequence> <xsd:element name="projeto" type="xsd:string"/> <xsd:element name="classe"> <xsd:complexType> <xsd:sequence> <xsd:element name="nome" type="xsd:string"/> <xsd:element name="descricao" type="xsd:string"/> <xsd:sequence> <xsd:element name="restricao" type="xsd:string"/> </xsd:sequence> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="propriedade"> <xsd:complexType> <xsd:sequence> <xsd:element name="nome" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="axioma"> <xsd:complexType> <xsd:sequence> <xsd:element name="descricao" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>

OOnnttoohhiieerraarrqquuiiaa..xxssdd

<?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

Anexo A 198

<xsd:element name="ontohierarquia"> <xsd:complexType> <xsd:sequence> <xsd:element name="projeto" type="xsd:string"/> <xsd:element name="classepai"> <xsd:complexType> <xsd:sequence> <xsd:element name="nome" type="xsd:string"/> <xsd:sequence> <xsd:element name="classefilho" type="xsd:string"> </xsd:element> </xsd:sequence> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>

Anexo B 199

ANEXO

BB

TELAS DO OORNF

AA sseegguuiirr aapprree sseennttaa mmooss aass ttee llaass ddoo ssiissttee mmaa OOOORRNNFF eemm ssuuaa nnoovvaa vveerrssããoo aallttee rraa ddaa,, qquuee ffooii cchhaa mmaaddaa ddee CCAALLEELL,, ccoomm oo eessttuuddoo ddee ccaassoo aapprreessee nnttaaddoo nnoo CCaappííttuulloo 55..

Anexo B 200

A seguir temos a tela do Menu principal da ferramenta CALEL:

Como podemos observar, nem todos os itens do Menu Principal estarão acessíveis em um primeiro momento, pois devemos escolher um projeto para podermos inserir os símbolos do LEL, entre outras opções. Porém, podemos acessar a tela dos RNF, onde podemos realizar as operações básicas nos Requisitos não funcionais (tela a seguir).

Anexo B 201

Primeiramente escolhemos/incluímos o nome do projeto:

A seguir vemos um exemplo do LEL, aqui tínhamos apenas alguns termos incluídos, e podemos observar que os termos que aparecem sublinhados são aqueles inclusos no projeto. À medida que inserimos novos símbolos este principio (de circularidade) se torna mais evidente.

Após a inserção de todos os símbolos, podemos tratar dos cenários. Para isto, podemos gerar os atores de forma automática, bem como os recursos. A seguir veremos as telas correspondentes.

Anexo B 202

Vale observar que todos os atores serão incluídos como sendo primários. A situação será alterada após a inserção dos atores nos cenários. Para a nomenclatura MDSODI será de acordo com o cenário tratado.

Anexo B 203

Anexo B 204

Após a geração automática dos atores e recursos, podemos gerar também os cenários. Alguns campos não serão preenchidos de forma automática, devendo existir a intervenção do operador. Para isso, ao acessar a tela de cenários Update/View, podemos alterar o cenário e, inclusive incluir novos cenários.

Na tela anterior, ao inserirmos os episódios podemos inserir restrições e sentenças pré-programadas (condicionais e opcionais) – tecla do botão direito no mouse.

Anexo B 205

A seguir podemos observar a inclusão de uma restrição OCL:

Após os episódios inseridos com suas respectivas restrições podemos gerar os aspectos candidatos, mostrado no exemplo a seguir.

Anexo B 206

Anexo B 207

A seguir mostraremos a tela para atualização dos aspectos e suas regras de composição.

Anexo B 208

Como podemos observar ele já irá trazer os aspectos relativos aos requisitos não funcionais, observe o campo ORIGIN indicando RNF. Ao clicarmos nos cenários afetados obtemos a opção de atualizarmos os cenários afetados pelo aspecto selecionado. Observe a tela abaixo:

Anexo B 209

Como podemos observar alguns campos não são preenchido pela geração automática dos aspectos, estes campos devem ser atualizados para que possamos depois gerar a tabela de conflitos. Se quisermos adicionar um cenário basta clicar no botão insert e ele irá mostrar todos os cenários do projeto, como mostra a tela abaixo:

Anexo B 210

Depois basta clicarmos em Select and Insert, para que o cenário seja incluído como cenário afetado.

A tela acima representa a verificação de conflitos entre os aspectos , de acordo com o especificado no projeto. A resolução destes conflitos é típica de projeto e deve ser efetuada com muito cuidado. Mostraremos agora o exemplo de como gerar a ontologia para o projeto selecionado. Isto é feito em algumas etapas, mostradas nas telas a seguir:

Gerando classes:

Anexo B 211

Após gerar as classes:

Gerando propriedades:

Anexo B 212

Agora, podemos atualizar as propriedades e classes geradas:

Anexo B 213

Para gerar hierarquias, devemos indicar a classe pai e as classes filhos, de acordo com a tela abaixo:

Ao indicarmos um nome para a classe pai, podemos ir na página dos filhos descendentes e colocarmos todas as classes filhos existentes. Conforme tela abaixo:

Anexo B 214

Finalmente, os arquivos XML gerados a partir dos XML Schema definidos (Anexo A), estão no anexo C.

Anexo C 215

ANEXO

CC

ARQUIVOS XML GERADOS NO ESTUDO DE CASO

AA sseegguuiirr aapprreessee nnttaammooss ooss aa rrqquuiivvooss XXMMLL ggee rraaddooss aattrraavvééss ddooss

XXMMLL SScchheemmaa pprroo ppoossttooss ccoomm oo eessttuuddoo ddee ccaassoo aapprreesseennttaa ddoo nnoo

CCaappííttuulloo 55..

Anexo C 216

AAssppeeccttooss ..xxmmll <?xml version="1.0"?> <Aspectos xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/AspectosLEL.xsd"> <Projeto id="-9223372036854775808" nome="string">   </Projeto> <aspecto_candidato> <id>1</id> <nome> Confidenciabilidade </nome> <origem>RNF</origem> <descricao> Garantir a autenticação e validação do usuario </descricao>  <cenariosafetados> <cenarioid>11</cenarioid> <nome_cenario>AA lltteerraa rr pp aarrtt iicc iipp aann ttee </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais>Se situaçãoOK então executa(ponto junção) Senão exibe (msgErro)

</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 22</cenarioid> <nome_cenario> EExxcc lluu iirr pp aarrtt iicciipp aann ttee </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 33</cenarioid> <nome_cenario> CCoo nn ss uu llttaarr pp aarrtt iicciipp aann tteess </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 44</cenarioid> <nome_cenario>-- CCaadd aass tt rraarr eevv eenn ttoo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais>

Anexo C 217

</cenariosafetados> <cenariosafetados> <cenarioid> CCNN ## 55</cenarioid> <nome_cenario> CCaadd aass tt rraarr ccoo mmiiss ss ããoo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 66</cenarioid> <nome_cenario> CCaadd aass tt rraarr ccoo mmiittêê </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 77</cenarioid> <nome_cenario> RReecceebb eerr rreeccuu rrss oo ss </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 88</cenarioid> <nome_cenario> DDiiss tt rriibb uu iirr rreeccuu rrss oo ss </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 99</cenarioid> <nome_cenario> PPaagg aarr ffoo rrnn eecceedd oo rr </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1100</cenarioid> <nome_cenario> RReecceebb eerr pp aagg aa mmeenn ttoo </nome_cenario> <condicao> </condicao>

Anexo C 218

<regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1122</cenarioid> <nome_cenario>-- IInn ss ccrreevv eerr--ss ee eemm eevv eenn ttoo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1133</cenarioid> <nome_cenario> EEnn vv iiaa rr tt rraabb aallhh oo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1144</cenarioid> <nome_cenario> EEffeettuu aarr pp aagg aammeenn ttoo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1155</cenarioid> <nome_cenario> EEnn vv iiaa rr pp aalleess tt rraa </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1166</cenarioid> <nome_cenario> CCaadd aass tt rraarr pp aarrcceeii rroo ss </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> CCNN ## 11 77</cenarioid>

Anexo C 219

<nome_cenario> EEnn vv iiaa rr mmaatteerr iiaa ll </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1188</cenarioid> <nome_cenario> EEmmiitt iirr ccee rrtt ii ffiiccaadd oo ss </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1199</cenarioid> <nome_cenario> AA ttuu aalliizzaa rr pp rroo gg rraa mmaaççããoo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> CCNN ## 22 00</cenarioid> <nome_cenario> SSee lleecc iioo nn aarr tt rraabb aallhh oo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 2211</cenarioid> <nome_cenario> FFoo rrnn eecceerr rreeccuu rrss oo ss </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 2222</cenarioid> <nome_cenario>SSee lleecciioo nn aarr mmiinn iiss tt rraann ttee</nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

Anexo C 220

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 2233</cenarioid> <nome_cenario> SSee lleecc iioo nn aarr pp aalleess tt rraann ttee </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 2244</cenarioid> <nome_cenario> EEmmiitt iirr cc rraacchh ááss </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 2255</cenarioid> <nome_cenario>-- EEnn vv iiaarr rreeqq uu iiss iiççããoo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> </aspecto_candidato> <!—Novo aspecto--> <aspecto_candidato> <id>2</id> <nome> Integridade </nome> <origem>RNF</origem> <descricao> Garantir a atualização através de pessoal autorizado e validado </descricao>  <cenariosafetados> <cenarioid> 11</cenarioid> <nome_cenario>AA lltteerraa rr pp aarrtt iicc iipp aann ttee </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais>Se situaçãoOK então executa(ponto junção) Senão exibe (msgErro)

</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 22</cenarioid> <nome_cenario> EExxcc lluu iirr pp aarrtt iicciipp aann ttee </nome_cenario>

Anexo C 221

<condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 22</cenarioid> <nome_cenario> EExxcc lluu iirr pp aarrtt iicciipp aann ttee </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 44</cenarioid> <nome_cenario>-- CCaadd aass tt rraarr eevv eenn ttoo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 55</cenarioid> <nome_cenario> CCaadd aass tt rraarr ccoo mmiiss ss ããoo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 66</cenarioid> <nome_cenario> CCaadd aass tt rraarr ccoo mmiittêê </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 77</cenarioid> <nome_cenario> RReecceebb eerr rreeccuu rrss oo ss </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais>

Anexo C 222

</cenariosafetados> <cenariosafetados> <cenarioid> 88</cenarioid> <nome_cenario> DDiiss tt rriibb uu iirr rreeccuu rrss oo ss </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 99</cenarioid> <nome_cenario> PPaagg aarr ffoo rrnn eecceedd oo rr </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1100</cenarioid> <nome_cenario> RReecceebb eerr pp aagg aa mmeenn ttoo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1122</cenarioid> <nome_cenario>-- IInn ss ccrreevv eerr--ss ee eemm eevv eenn ttoo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1133</cenarioid> <nome_cenario> EEnn vv iiaa rr tt rraabb aallhh oo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1144</cenarioid> <nome_cenario> EEffeettuu aarr pp aagg aammeenn ttoo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao>

Anexo C 223

<informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1155</cenarioid> <nome_cenario> EEnn vv iiaa rr pp aalleess tt rraa </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> CCNN ## 11 66</cenarioid> <nome_cenario> CCaadd aass tt rraarr pp aarrcceeii rroo ss </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1177</cenarioid> <nome_cenario> EEnn vv iiaa rr mmaatteerr iiaa ll </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1188</cenarioid> <nome_cenario> EEmmiitt iirr ccee rrtt ii ffiiccaadd oo ss </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 1199</cenarioid> <nome_cenario> AA ttuu aalliizzaa rr pp rroo gg rraa mmaaççããoo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid>22 00</cenarioid>

Anexo C 224

<nome_cenario> SSee lleecc iioo nn aarr tt rraabb aallhh oo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 2211</cenarioid> <nome_cenario> FFoo rrnn eecceerr rreeccuu rrss oo ss </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> CCNN ## 22 22</cenarioid> <nome_cenario>SSee lleecciioo nn aarr mmiinn iiss tt rraann ttee</nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 2233</cenarioid> <nome_cenario> SSee lleecc iioo nn aarr pp aalleess tt rraann ttee </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 2244</cenarioid> <nome_cenario> EEmmiitt iirr cc rraacchh ááss </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

(msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 2255</cenarioid> <nome_cenario>-- EEnn vv iiaarr rreeqq uu iiss iiççããoo </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaçãoOK então executa(ponto junção) Senão exibe

Anexo C 225

(msgErro)</informacoesadicionais> </cenariosafetados> </aspecto_candidato> <!—novo aspecto--> <aspecto_candidato> <id>3</id> <nome> CPF_Cliente </nome> <origem>RF</origem> <descricao> Verificar se o cliente esta com obrigações em dia </descricao>  <cenariosafetados> <cenarioid> 1122</cenarioid> <nome_cenario> IInnss ccrreevvee rr--ssee eemm eevvee nnttoo </nome_cenario> <condicao> </condicao> <regracomposicao> wrap </regracomposicao> <pontojuncao>3</pontojuncao> <informacoesadicionais>Se situaçãoOK então executa(ponto junção) Senão exibe (msgErro)

</informacoesadicionais> </cenariosafetados> </aspecto_candidato> <!—novo aspecto--> <aspecto_candidato> <id>4</id> <nome> Validar situaçao </nome> <origem>RO</origem> <descricao> Verificar se cliente VIP </descricao>  <cenariosafetados> <cenarioid> 1122</cenarioid> <nome_cenario> IInnss ccrreevvee rr--ssee eemm eevvee nnttoo </nome_cenario> <condicao> </condicao> <regracomposicao> overlap.after </regracomposicao> <pontojuncao>3</pontojuncao> <informacoesadicionais>Se executa(ponto junção) então aplicardesconto() Senão verificar

potencial() </informacoesadicionais> </cenariosafetados>  <cenariosafetados> <cenarioid>11 44</cenarioid> <nome_cenario> EEffee ttuuaarr ppaaggaammee nnttoo</nome_cenario> <condicao> </condicao> <regracomposicao> overlap.before </regracomposicao> <pontojuncao>3</pontojuncao> <informacoesadicionais>Se executa(ponto junção) então aplicardesconto() Senão verificar

potencial() </informacoesadicionais> </cenariosafetados> </aspecto_candidato> </Aspectos>

Anexo C 226

SSiimmbboollooss..xxmmll <?xml version="1.0"?> <Projeto xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/LELSimbolos.xsd"> <id_projeto>1</id_projeto> <dominio>comunicaçao</dominio> <nome_projeto>Eventos</nome_projeto> <descricao>Controle e gerencia de eventos cientificos</descricao> <LEL> <id_simbolo>1</id_simbolo> <nome_simbolo>secretaria</nome_simbolo> <categoria>sujeito</categoria> <sinonimos> <alias>secretaria</alias> <alias>auxiliar</alias>

1. </sinonimos> <nocoes> <id_nocao>1</id_nocao> <descricao_nocao>Pessoa que auxilia na gerencia do evento </descricao_nocao> </nocoes> <impactos> <id_impacto>1</id_impacto> <descricao_impacto> ccaaddaa ssttrraa rr cc lliieennttee </descricao_impacto> <id_impacto>2</id_impacto> <descricao_impacto> ccoonnss uulltt aa eevveennttoo ss ee mm aabb eerrttoo</descricao_impacto> <id_impacto>3</id_impacto> <descricao_impacto> ccoonnss uullttaa eevveennttooss ffeecchhaaddooss</descricao_impacto> <id_impacto>4</id_impacto> <descricao_impacto> aa lltteerr aarr ppaarr tt iicc iippaannttee</descricao_impacto> <id_impacto>5</id_impacto> <descricao_impacto> eexxcc lluuiirr ppaarr tt iicc iippaannttee</descricao_impacto> <id_impacto>6</id_impacto> <descricao_impacto> ccoonnss uullttaa rr ppaarrtt iicc iipp aanntteess</descricao_impacto> <id_impacto>7</id_impacto> <descricao_impacto> ccaaddaass ttrraa rr eevveennttooss</descricao_impacto> <id_impacto>8</id_impacto> <descricao_impacto> ccaaddaass ttrraarr ccoo mmiissssããoo</descricao_impacto> <id_impacto>9</id_impacto> <descricao_impacto> ccaaddaass ttrraarr ccoo mmiittêê</descricao_impacto> <id_impacto>10</id_impacto> <descricao_impacto> rreecceebbeerr rreeccuurrssooss</descricao_impacto> <id_impacto>11</id_impacto> <descricao_impacto> ppaaggaarr ffoo rr nneecceeddoorr</descricao_impacto> <id_impacto>12</id_impacto> <descricao_impacto> dd iisstt rr iibbuuiirr rreeccuurrssooss</descricao_impacto> <id_impacto>13</id_impacto> <descricao_impacto> rreecceebbee rr ppaaggaa mmeennttoo</descricao_impacto>

Anexo C 227

</impactos> </LEL> <LEL> <id_simbolo>2</id_simbolo> <nome_simbolo>participante</nome_simbolo> <categoria>sujeito</categoria> <sinonimos> <alias>participantes</alias> </sinonimos> <nocoes> <id_nocao>1</id_nocao> <descricao_nocao> PPeessssooaa qquuee ppaarr tt iicc iippaa ddee uumm eevveennttoo ccoo mmoo :: oouuvviinnttee,, aapprreesseennttaaddoo rr,, ppaa llee ssttrraannttee,, mmiinniiss ttrraannttee </descricao_nocao> </nocoes> <impactos> <id_impacto>1</id_impacto> <descricao_impacto> ccoonnss uulltt aa eevveennttoo ss ee mm aabbee rrttoo </descricao_impacto> <id_impacto>2</id_impacto> <descricao_impacto> ccoonnss uullttaa eevveennttooss ffeecchhaaddoo ss </descricao_impacto> <id_impacto>3</id_impacto> <descricao_impacto> ccoonnss uullttaa rr pprrooggrr aa mmaaççaaoo </descricao_impacto> </impactos> </LEL> <!—Os outros Elementos do LEL foram suprimidos para que ficasse menor o arquivo--> </Projeto>

Anexo C 228

CCeennaarriiooss..xxmmll <?xml version="1.0"?> <Projeto xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/LELCenario.xsd"> <id_projeto>1</id_projeto> <dominio>comunicacao</dominio> <nome_projeto>Eventos</nome_projeto> <descricao> Controle e gerencia de eventos cientificos </descricao> <cenarios> <Tipo_mdsodi>paralelo</Tipo_mdsodi> <cenarioid>1</cenarioid> <titulo>CCoonnss uullttaarr eevveennttooss ee mm aabbeerr ttoo</titulo> <objetivo>PPrroocceedd iimmeennttoo pp aarraa qquuaannddoo ddeess eejjaa-- ssee ccoonnhheeccee rr ttooddooss ooss eevveennttooss qquuee eessttããoo ee mm aabbeerr ttoo</objetivo> <contexto> <texto>SS iissttee mmaa ee mmiitt iinnddoo ccoonnss uullttaa ddee eevveennttooss ee mm aabbeerr ttoo</texto> </contexto> <atores> <nome> sseeccrr eettáárr iiaa </nome> <tipo_ator>primario</tipo_ator> </atores> <atores> <nome> ppaarr tt iicc iippaannttee </nome> <tipo_ator>primario</tipo_ator> </atores> <atores> <nome> ppaarrccee iirrooss </nome> <tipo_ator>secundario</tipo_ator> </atores> <atores> <nome> cc lliieennttee ss iinncc lluuiiddooss </nome> <tipo_ator>primario</tipo_ator> </atores> <atores> <nome> cc lliieennttee ss </nome> <tipo_ator>secundario</tipo_ator> </atores> <recursos> <descricao>evento</descricao> </recursos> <episodios> <texto> SS iissttee mmaa eexxiibbee eevveennttooss ee mm aabbeerr ttoo </texto> <RNFEspecifico> <texto></texto> <estrategia></estrategia> </RNFEspecifico> <ExpressaoOCL> <texto> </texto>

Anexo C 229

</ExpressaoOCL> <Rorg> <texto></texto> <estrategia></estrategia> </Rorg> </episodios> </cenarios> <!—Os outros elementos foram suprimidos --> </Projeto>

Anexo C 230

OOnnttoollooggiiaa..xxmmll <?xml version="1.0"?> <ontologias xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/ontologia.xsd"> <projeto>Eventos</projeto> <classe> <nome>apresentador</nome> <descricao> Cliente inscrito para apresentar trabalho </descricao> <restricao></restricao> <nome>trabalho</nome> <descricao> AArrttiiggooss aa sseerreemm aapprreesseennttaaddooss eemm uumm eevveennttoo </descricao> <restricao></restricao> <nome>comite</nome> <descricao> GGrruuppoo ddee ppeessssooaass sseelleecciioonnaaddaass ppaarraa sseelleecciioonnaarr ooss ttrraabbaallhhooss aapprreesseennttaaddooss nnoo

eevveennttoo</descricao> <restricao></restricao> <nome>participante</nome> <descricao> PP eessssooaa qquuee ppaarrttiicciippaa ddee uumm eevveennttoo ccoommoo:: oouuvviinnttee,, aapprreesseennttaaddoorr,, ppaalleessttrraannttee,,

mmiinniissttrraannttee</descricao> <restricao></restricao> <nome>evento</nome> <descricao> CCoonnffeerreenncciiaa oouu WWoorrkksshhoopp aa sseerr ggeerreenncciiaaddoo ppeellaa eemmpprreessaa.. CCaaddaa eevveennttoo ppoossssuuii

uumm ppeerrííooddoo ddee rreeaalliizzaaççããoo </descricao> <restricao></restricao> <nome>cliente inscrito</nome> <descricao> PP eessssooaa qquuee ssoolliicciittoouu oo ccaaddaassttrroo ee ffooii aapprroovvaaddaa,, rreecceebbeennddoo oo sseeuu llooggiinn ee sseennhhaa

</descricao> <restricao></restricao> <nome>programacao</nome> <descricao> CCrroonnooggrraammaa aa sseerr ccuummpprriiddoo ddoo eevveennttoo.. CCoonntteemm aass ppaalleessttrraass,, ttrraabbaallhhooss ee ccuurrssooss

aa sseerreemm aapprreesseennttaaddooss nnoo eevveennttoo </descricao> <restricao></restricao> <nome>comissao</nome> <descricao> : GGrruuppoo ddee ppeessssooaass sseelleecciioonnaaddaass ppaarraa ggeerreenncciiaarr oo eevveennttoo </descricao> <restricao></restricao> <nome>ministrante</nome> <descricao> Cliente inscrito para ministrar curso </descricao> <restricao></restricao> <nome>material</nome> <descricao> OO mmaa tteerr iiaa ll rree ffeerreennttee aaoo ccuurrssoo aa ssee rr mmiinniiss ttrraaddoo ee mm uumm eevveennttoo </descricao> <restricao></restricao> <nome>requisicao</nome> <descricao> Documento que contem referencias aos recursos materiais necessários para realizar a tarefa </descricao> <restricao></restricao> <nome>palestrante</nome> <descricao> Cliente inscrito para ministrar palestra </descricao>

Anexo C 231

<restricao></restricao> <nome>palestra</nome> <descricao>Slides referentes a um assunto a ser apresentado no evento </descricao> <restricao></restricao> <nome>crachá</nome> <descricao> IIddeenntt iiffiiccaaççããoo ddoo ppaarr tt iicc iippaannttee ddoo eevveennttoo </descricao> <restricao></restricao> <nome>certificado</nome> <descricao> CCoommpp rroovvaannttee ddee pp aarrtt iicc iippaaççããoo ddoo eevveennttoo </descricao> <restricao></restricao> <nome>patrocinador</nome> <descricao> EEmmpprreessaa qquuee ffoorrnneecceemm rreeccuurrssooss ffiinnaanncceeiirrooss ppaarraa aa rreeaalliizzaaççããoo ddoo eevveennttoo </descricao> <restricao></restricao> <nome>recursos</nome> <descricao> São materiais necessários para a realização e elaboração do evento. </descricao> <restricao></restricao> <nome>pagamento</nome> <descricao> Comprovante de quitação com o evento</descricao> <restricao> Podem ser: financeiro, humano e material </restricao> <nome>ouvinte</nome> <descricao> Cliente inscrito para assistir aos cursos, palestras e apresentações do evento

</descricao> <restricao></restricao> <nome>cliente</nome> <descricao> : PPeess ssooaa qquuee aa iinnddaa nnããoo ssoo lliicc iittoouu oo ccaaddaass ttrroo,, aappeennaass cc lliieennttee ee mm ppoott eenncc iiaa ll </descricao> <restricao></restricao> <nome>inscricao</nome> <descricao> IIddeenntt iiffiiccaaççããoo ddee uumm cc lliieennttee qquuaannddoo ddeess eejjaa ffaazzeerr sseeuu ccaaddaasstt rroo </descricao> <restricao></restricao> <nome>secretaria</nome> <descricao> PP eessssooaa qquuee aauuxxiilliiaa nnoo ggeerreenncciiaammeennttoo ddoo eevveennttoo </descricao> <restricao></restricao> <nome>fornecedor</nome> <descricao> EEmmpprreessaa qquuee ffoorrnneeccee rreeccuurrssooss ((mmaatteerriiaaiiss oouu hhuummaannooss)) ppaarraa aa rreeaalliizzaaççããoo ddoo

eevveennttoo </descricao> <restricao></restricao> </classe> <nome> Aberto</nome> <descricao> são os eventos que possuem o período de realização maior ou igual do que a data atual </descricao> <restricao> subClasseOf: tipo-evento </restricao> <nome> fechado</nome> <descricao> são os eventos que possuem o período de realização menor do que a data

Anexo C 232

atual </descricao> <restricao> subClasseOf: tipo-evento </restricao> <nome> Tipo-Evento</nome> <descricao> conjunto dos estados possíveis em que o evento pode estar no momento.Partição de valor.</descricao> <restricao> </restricao> <propriedade> <nome> é-enviado</nome> <nome> é-selecionado</nome> <nome> é-apresentado</nome>

<nome> é-alterado</nome> <nome> é-consultado</nome>

<nome> é-inscrito</nome> <nome> é-elaborado</nome> <nome> é-enviado</nome>

<nome> é-emitido</nome> <nome> é-fornecido</nome>

<nome> é-pago</nome> <nome> é-solicitado</nome> <nome> é-excluído</nome>

<nome> é-distribuído </nome> </propriedade> <axioma> <descricao> Trabalho pode ser: full, short, poster </descricao> </axioma> </ontologias>

Anexo C 233

hhiieerraarrqquuiiaa..xxmmll <?xml version="1.0"?> <ontohierarquia xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/ontohierarquia.xsd"> <projeto>Eventos</projeto> <classepai> <nome> Parceiros </nome> <classefilho> fornecedor</classefilho> <classefilho> patrocidador </classefilho> <nome> Cliente </nome> <classefilho> cliente inscrito </classefilho> <classefilho> cliente </classefilho> <classefilho> participante (ouvinte, palestrante, apresentador, ministrante)</classefilho> <nome> Recursos</nome> <classefilho> materiais ou humanos </classefilho> <classefilho> financeiros </classefilho> <nome> Material_evento</nome> <classefilho> palestra </classefilho> <classefilho> curso </classefilho> <classefilho> apresentação </classefilho> <classefilho> requisição </classefilho> <nome> Grupo_trabalho</nome> <classefilho> secretária </classefilho> <classefilho> comitê </classefilho> <classefilho> comissão </classefilho> <nome> Objetos_evento</nome> <classefilho> crachá </classefilho> <classefilho> certificado </classefilho> <classefilho> programação </classefilho> </classepai> </ontohierarquia>

· ii dados internacionais de catalogação-na-publicação (cip) biblioteca central do campus de...

Documents