A Engenharia de Requisitos Orientada A Aspectos - A Abordagem DAORE (Luciana de Paiva Silva)

LUCIANA DE PAIVA SILVA
A ENGENHARIA DE REQUISITOS ORIENTADA A ASPECTOS: A ABORDAGEM DAORE
MARING 2007
Dados Internacionais de Catalogao-na-Publicao (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 Dissertao (Mestrado) Universidade Estadual de Maring. Programa de Ps- Graduao em Cincia da Computao. Bibliografia.
1. Sistemas de informa o. 2. Orientao a aspectos. 3. Engenharia de requisitos. I. Tait, Tania F. Calvi. II. Universidade Estadual de Maring. III. Ttulo. CDD 21ed. 005.1 CIP NBR 12899 Ficha catalogrfica elaborada por Jeanine Barros CRB-9/1362
ii
LUCIANA DE PAIVA SILVA
A ENGENHARIA DE REQUISITOS ORIENTADA A ASPECTOS: A ABORDAGEM DAORE
Dissertao apresentada ao Programa de Ps-Graduao em Cincia da Computao da Universidade Estadual de Maring, como requisito parcial para obteno do grau de Mestre em Cincia da Computao. Orientadora: Profa. Dra. Tania Fatima Calvi Tait
MARING 2007
iii
Ao que foi e que sempre ser meu apoio, meu amigo, meu cmplice e meu marido: Srgio.
iv
AGRADECIMENTOS
Nada mais difcil, e por isso mais precioso, do que ser capaz de decidir.
Napoleo
Apoiar do Latim Appodiare significa ajudar, confirmar, dar apoio, fundar-se.. Todas as conquistas so repletas de dificuldades e, para venc-las, necessrio apoio em todas as formas. O apoio recebido ajuda no desenvolvimento de um projeto, seja ele pessoal ou comunitrio. As pessoas aqui listadas ofereceram um tipo de apoio, que imprescindvel a qualquer projeto, a fora que move montanhas... o apoio que vence barreiras de distncias, 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 fora 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 dedicao, por todos os sacrifcios 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 distncia 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 cmplice e meu companheiro de sempre, Sergio, que com seu amor incondicional me impulsionaram a buscar mais uma realizao, mais uma conquista, e por despertar em mim uma admirao crescente e constante; A minha av Nina, seu apoio espiritual foi imprescindvel para a realizao dos meus sonhos; A minha amiga Aline, por ser minha irm e minha companheira dos momentos felizes e infelizes em nossa estada em Maring; v
Agradecimentos
A minha orientadora Tnia, pelo incentivo, confiana e pela parceria nas idias e discurses, alem de agentar minhas reclamaes; A professora Elisa, por ter me propiciado o primeiro contato com a orientao a aspectos e pelas importantes contribuies para o enriquecimento desta dissertao; Aos pesquisadores com os quais me correspondi, e s p e c i a l m e n t e a A w a i s R a shid, 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, d o C i n - UFPE, pela pacincia e bom humor durante esta fase do mestrado; Ao Departamento de Informtica da UEM, tcnico e acadmico durante minha estada; e pelo suporte
A todos aqueles que torceram e acreditaram em mim e neste trabalho.
vi
H duas formas para viver sua vida: uma acreditar que no existe milagre; a outra acreditar que todas as coisas so um milagre.
Albert Einstein
Porque para Deus nada impossvel.

Lucas 1,37
vii
Resumo
SILVA, Luciana de Paiva. A Engenharia de Requisitos Orientada a Aspectos: A Abordagem DAORE. 233f. Dissertao (Mestrado em Cincia da Computao) Programa de Ps- Graduao em Cincia da Computao, UEM,Maring.
Ao desenvolvermos um projeto de sistemas de informao, geralmente no modelamos os chamados crosscuting concerns, tendemos a modelar algumas caractersticas isoladas e no realizamos a separao e composio destas caractersticas. A orientao a aspectos permite a modelagem destas caractersticas nos projetos, possibilitando a identificao de caractersticas comuns em vrias partes do sistema. Inicialmente voltada para a implementao e agora com vrias pesquisas relacionadas s fases iniciais do desenvolvimento do processo de software, a orientao a aspectos permite que se obtenha muitas vezes os requisitos aspectuais, ou seja, os aspectos identificados nas fases iniciais do processo de desenvolvimento, que so fatores importantes e imprescindveis desde o incio do projeto de sistemas. Assim, este projeto de dissertao insere-se num tema que tem recebido crescente ateno no processo de desenvolvimento de sistemas: a aplicao da orientao a aspectos nas fases iniciais do processo de desenvolvimento, ou como conhecida na linguagem aspectos: early aspects. Este trabalho realiza um estudo e anlise de algumas das abordagens existentes na fase de engenharia de requisitos por meio da introduo de uma nova abordagem, denominada DAORE Distributed Aspect Oriented Approach for Requirements Engineering, como soluo para aplicao do LEL Lxico Extendido da Linguagem e da metodologia MDSODI - Methodology for Development of Distributed Software, permitindo a definio 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.
viii
Abstract
SILVA, Luciana de Paiva. A Engenharia de Requisitos Orientada a Aspectos: A Abordagem DAORE. 233f. Dissertao (Mestrado em Cincia da Computao) Programa de Ps- Graduao em Cincia da Computao, 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.
ix
Lista de Abreviaturas
AOD AORE DiSEN DAORE I* LAL LEL MDSODI NFR POA POO UML RE RF RNF RO XML Aspect Oriented Development Aspects Oriented Requirement Engineering Distributed Software Engineering Environment Distributed Aspect Oriented Approach for Requirements Engineering Distributed Intentionality Lxico Ampliado da Linguagem Language Extended Lexicon ou Lxico Extendido da Linguagem Methodology for Development of Distributed Software Non-functional Requirements Programao orientada a aspectos Programao orientada a objetos Unified Modeling Language Engenharia de Requisitos Requisitos Funcionais Requisitos no-funcionais Requisitos organizacionais Extensible Markup Language
Lista de Figuras
CAPTULO 1 FIGURA 1.1 CAPTULO 2 FIGURA 2.1 FIGURA 2.2 FIGURA 2.3 FIGURA 2.4 FIGURA 2.5 FIGURA 2.6 FIGURA 2.7 FIGURA 2.8 FIGURA 2.9 FIGURA 2.10 FIGURA 2.11 FIGURA 2.12 FIGURA 2.13 FIGURA 2.14 FIGURA 2.15 FIGURA 2.16 FIGURA 2.17 FIGURA 2.18 FIGURA 2.19 FIGURA 2.20 FIGURA 2.21 FIGURA 2.22 FIGURA 2.23 CAPTULO 3 FIGURA 3.1 FIGURA 3.2 FIGURA 3.3 FIGURA 3.4 FIGURA 3.5 FIGURA 3.6 FIGURA 3.7 FIGURA 3.8 CAPTULO 4 FIGURA 4.1 FIGURA 4.2 FIGURA 4.3 FIGURA 4.4 ESTRUTURA DA PESQUISA A SER SEGUIDA .......................................... 9
MODELO DE S EPARAO AVANADA DE CONCERNS......................... PROCESSO DE COMBINAO DE ASPECTOS E CLASSES PARA GERAR O SISTEMA............................................................................................. ESTRUTURA DE UMA ENTIDADE ASPECT EM ASPECTJ....................... EXEMPLO DE CDIGO EM ASPECTJ.................................................... MODELO DE PROCESSO AORE........................................................... EXEMPLO DE CASO DE USO COM ASPECTO CANDIDATO.................... USE CASE DE OVERLAP DO ASPECTO SEGURANA.............................. EXEMPLO DE REGRA DE COMPOSIO............................................... O GRFICO V-GRAPH E SUA COMPOSIO.......................................... O GRFICO V-GRAPH E SUA REPRESENTAO................................... A VISO GERAL DA ABORDAGEM GOAL............................................. ATUALIZAO DOS MODELOS NO DESENVOLVIMENTO....................... EFEITOS DE DISPERSO E ENROLAO QUANDO REALIZAMOS PEERS.. EXEMPLO DE EXTENSION................................................................... ESTRUTURA DOS ELEMENTOS E CASOS DE USO SLICES........................ COMPOSIO DA REALIZAO DE CASOS DE USO PEER COM CASOS DE USO SLICES.................................................................................... REPRESENTAO DE CASOS DE USO.................................................. ESTRUTURANDO CASOS DE USO DE INFRA- ESTRUTURA..................... A ESPECIFICAO DO CASO DE USO <PERFORM TRANSACTION>....... O PROCESSO THEME........................................................................... EXEMPLO ABSTRATO DO GRFICO DE VISO DE AES.................... EXEMPLO ABSTRATO DO GRFICO DE AES LIGADAS..................... EXEMPLO ABSTRATO DO GRFICO DE THEME VIEW..........................
18 23 25 25 27 34 35 37 38 38 39 42 43 44 45 45 46 46 47 49 52 53 54
CICLO DE VIDA DO MDSODI............................................................. O AMBIENTE DISEN E SUA ESTRUTURA EM CAMADAS....................... REPRESENTAO DO GERENCIADOR DE WORSPACE .......................... MODELO DE P ROCESSO UTILIZADO NA REQUISITE......................... DIAGRAMA USE CASE DA FERRAMENTA REQUISITE....................... ARQUITETURA DETALHADA DA FERRAMENTA REQUISITE.............. ESQUEMA DE INSTNCIAS DA FERRAMENTA REQUISITE................ REPRESENTAO DA ARQUITETURA DO DISEN.................................
MODELO DE P ROCESSO DA ABORDAGEM DAORE..................................... P ROCESSO GERAL DE COSNTRUO DE REQUISITOS.................................. UMA TAXONOMIA PARA RNFS. ................................................................. MODELO DE P ROCESSO DE CONSTRUO DO LEL N A ABORDAGEM DAORE......................................................................................................
66 70 72 73 74 77 79 80
89 90 93 101
xi
Lista de Figuras
CAPTULO 5 FIGURA 5.1 FIGURA 5.2 FIGURA 5.3 FIGURA 5.4 FIGURA 5.5 FIGURA 5.6 FIGURA 5.7 FIGURA 5.8 FIGURA 5.9 CAPTULO 6 FIGURA 6.1 FIGURA 6.2 FIGURA 6.3 FIGURA 6.4 FIGURA 6.5 FIGURA 6.6 FIGURA 6.7 FIGURA 6.8 FIGURA 6.9 FIGURA 6.10 FIGURA 6.11 FIGURA 6.12
MENU P RINCIPAL DA FERRAMENTA CALEL TELA DE INCLUSO DO LEL O PROCESSO DE MAPEAMENTO LEL ONTOLOGIAS
MAPEAMENTO DOS SMBOLOS DO TIPO ESTADO ESTRUTURA HIERRQUICA DA ONTOLOGIA EVENTOS TRECHO DO ARQUIVO DO LEL DOS SMBOLOS EM XML TRECHO DO ARQUIVO DO LEL DOS CENRIOS EM XML TRECHO DO ARQUIVO DE ASPECTOS XML TRECHO DO ARQUIVO DE ONTOLOGIAS XML
118 119 147 153 154 155 155 156 156
MENU P RINCIPAL DA FERRAMENTA REQUISITE NETBEANS E A FERRAMENTA REQUISITE BORLAND TOGETHER ARCHITECT E A REQUISITE DIAGRAMA DE CASOS DE USO DA REQUISITE PROPOSTO DIAGRAMA DE CLASSES PROPOSTO DA NOVA VERSO DA REQUISITE TELA DE ACESSO AO REQUISITE NOVO M ENU PRINCIPAL DA FERRAMENTA REQUISITE SUB-MENU DE P ROJECT NEW PROJECT SUB-MENU DA OPO LEL NEW/UPDATE LEL SUB-MENU DA OPO USE CASE
160 161 162 163 165 166 167 167 168 169 170 171
xii
Lista de Tabelas
CAPTULO 2 TABELA 2.1 RELACIONANDO PROPRIEDADES COM REQUISITOS DOS STAKEHOLDERS..................................................................................... TABELA 2.2 MAPEAMENTO ENTRE ASPECTOS CANDIDATOS...................................... TABELA 2.3 EXEMPLO DE UMA ESPECIFICAO DA DIMENSO DO ASPECTO........... TABELA 2.4 TEMPLATE PARA ATRIBUTOS DE QUALIDADE......................................... TABELA 2.5 TEMPLATE PARA REQUISITOS NO FUNCIONAIS..................................... TABELA 2.6 IDENTIFICAO DE MATCH POINTS....................................................... TABELA 2.7 CONTRIBUIO E CORRELAO............................................................ TABELA 2.8 CARACTERSTICAS DE QUALIDADE ISO/IEC 9126................................ TABELA 2.9 ADAPTAO DOS CONCEITOS DAS CARACTERSTICAS DE QUALIDADE ISO/IEC 9126....................................................................................... TABELA 2.10 SUB-CARACTERSTICAS DE COMPARAO............................................ TABELA 2.11 CRITRIOS DE PADRES UTILIZADOS NA COMPARAO....................... TABELA 2.12 COMPARAO DAS ABORDAGENS AORE.............................................. TABELA 2.13 RESUMO DA COMPARAO ABORDAGEM VIEWPOINT........................ TABELA 2.14 RESUMO DA COMPARAO ABORDAGEM GOALS............................... TABELA 2.15 RESUMO DA COMPARAO ABORDAGEM USE CASE.......................... TABELA 2.16 RESUMO DA COMPARAO ABORDAGEM THEME/DOC................... TABELA 2.17 RESUMO GERAL DA COMPARAO....................................................... CAPTULO 3 TABELA 3.1 ESPECIFICAO DOS ELEMENTOS UTILIZADOS NA MDSODI CAPTULO 4 TABELA 4.1 CONCEITOS E ARTEFATOS USADOS NA DAORE.................................... TABELA 4.2 RELAO ENTRE DIRETRIZES DA DAORE E AS CARACTERSTICAS DE QUALIDADE.......................................................................................... TABELA 4.3 RNFS E ESTRATGIAS DE SATISFAO.................................................. TABELA 4.4 MAPEAMENTO DOS REQUISITOS NO FUNCIONAIS E FUNCIONAIS ....... TABELA 4.5 MAPEAMENTO DOS REQUISITOS ORGANIZACIONAIS EM REQUISITOS FUNCIONAIS E NO FUNCIONAIS............................................................ TABELA 4.6 CONTRIBUIES DOS ASPECTOS............................................................ TABELA 4.7 COMPOSIO DOS ASPECTOS IDENTIFICADOS....................................... TABELA 4.8 EXEMPLO DE PREENCHIMENTO DA TABELA DE CONFLITOS.................. TABELA 4.9 MAPEAMENTO DOS ELEMENTOS DO LEL PARA OS ELEMENTOS DA ONTOLOGIA........................................................................................... TABELA 4.10 EXEMPLO DE HIERARQUIA DE CLASSES.................................................. TABELA 4.11 DAORE E OS OBJETIVOS PROPOSTOS................................................... CAPTULO 5 TABELA 5.1 REQUISITOS DO SISTEMA....................................................................... TABELA 5.2 REQUISITOS NO FUNCIONAIS E ORGANIZACIONAIS DO SISTEMA......... TABELA 5.3 SMBOLOS DO LEL ENCONTRADOS NOS REQUISITOS FUNCIONAIS......... TABELA 5.4 SMBOLOS DO LEL DETALHADO............................................................ TABELA 5.5 INCLUSO DOS REQUISITOS NO FUNCIONAIS........................................ xiii 28 29 30 31 32 36 39 41 55 56 57 59 60 61 62 63 63
68
84 86 94 98 100 104 105 106 107 108 110
117 117 119 120 128
Lista de Tabelas TABELA 5.6 TABELA 5.7 TABELA 5.8 TABELA 5.9 TABELA 5.10 TABELA 5.11 TABELA 5.12 TABELA 5.13 INCLUSO DOS REQUISITOS ORGANIZACIONAIS..................................... MAPEAMENTO ENTRE OS TERMOS DO LEL............................................ CENRIOS DO LEL................................................................................ CONTRIBUIES DOS ASPECTOS............................................................ COMPOSIO DOS ASPECTOS IDENTIFICADOS....................................... RESOLUO DE CONFLITOS................................................................... TERMOS DO LEL LISTADOS SEGUNDO O SEU TIPO................................. MAPEAMENTO REALIZADO.................................................................... 128 129 130 141 142 146 149 150
CAPTULO 6 TABELA 6.1 MAPEAMENTO ENTRE AS VERSES DA REQUISITE.................................
172
xiv
ndice
AGRADECIMENTOS................................................................................................ RESUMO.................................................................................................................... ABSTRACT................................................................................................................ LISTA DE ABREVIATURAS................................................................................... LISTA DE FIGURAS................................................................................................. LISTA DE TABELAS................................................................................................ 1. INTRODUO.................................................................................................. 1.1 CONTEXTO............................................................................................... 1.2 PROBLEMA............................................................................................... 1.3 CONTRIBUIES....................................................................................... 1.4 OBJETIVOS............................................................................................... 1.5 JUSTIFICATIVA.......................................................................................... 1.6 ESCOPO DA DISSERTAO........................................................................ 1.7 METODOLOGIA......................................................................................... 1.8 ORGANIZAO DA DISSERTAO............................................................. 2. DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS....... 2.1 CONCEITOS GERAIS DE AOSD................................................................. 2.1.1 CONCEITOS DE ASPECTOS, CONCERN E CROSSCUTTING CONCERNS................................................................................. 2.1.2 SEPARAO DE PROPRIEDADES................................................. 2.1.3 COMPOSIO DE PROPRIEDADES.............................................. 2.1.4 A PROGRAMAO ORIENTADA A ASPECTOS E A LINGUAGEM ASPECTJ................................................................................... 2.2 FASE DE REQUISITOS............................................................................... 2.2.1 ABORDAGEM DE VIEWPOINT..................................................... 2.2.2 ABORDAGEM AORE UTILIZANDO UML................................... 2.2.3 ABORDAGEM GOALS............................................................... 2.2.4 ABORDAGEM COM CASOS DE USO............................................. 2.2.5 ABORDAGEM THEME/DOC...................................................... 2.3 COMPARAO DAS ABORDAGENS APRESENTADAS.................................. 2.4 RESUMO DO CAPTULO............................................................................ A METODOLOGIA MDSODI E O AMBIENTE DISEN................................. 3.1 A M ETODOLOGIA MDSODI..................................................................... 3.2 O AMBIENTE DISEN................................................................................ 3.3 A FERRAMENTA REQUISITE................................................................. 3.3.1 ASPECTOS FUNCIONAIS............................................................. 3.3.2 A ARQUITETURA DA REQUISITE............................................. 3.3.3 EXEMPLO DE I NSTNCIAS DA REQUISITE NO DISEN............. 3.4 RESUMO DO CAPTULO............................................................................. A ABORDAGEM DAORE................................................................................ 4.1 OBJETIVOS E DIRETRIZES P RINCIPAIS....................................................... 4.2 O PROCESSO DE DESENVOLVIMENTO PROPOSTO...................................... 4.2.1 FASE 1 CONSTRUO DOS REQUISITOS.................................. iv vii viii ix x xiii 1 1 4 6 6 7 7 8 10 12 13 14 15 20 22 26 26 30 37 42 48 54 64 65 66 70 72 74 76 79 81 82 83 89 90
4.
xv
ndice 4.2.1.1 LEVANTAMENTO DOS REQUISITOS.............................. 4.2.1.2 CONSTRUO DE REQUISITOS FUNCIONAIS................. 4.2.1.3 CONSTRUO DE REQUISITOS NO FUNCIONAIS......... 4.2.1.4 CONSTRUO DE REQUISITOS ORGANIZACIONAIS...... 4.2.2 FASE 2 CONSTRUO DO LEL............................................... 4.2.3 FASE 3 DEFININDO ASPECTOS CANDIDATOS........................... 4.2.3.1 IDENTIFICANDO CONTRIBUIES............................ 4.2.3.2 DEFININDO COMPOSIO........................................ 4.2.3.3 IDENTIFICANDO CONFLITOS.................................... 4.2.4 FASE 4 - MAPEAMENTO DE ONTOLOGIAS................................. 4.2.5 GERAO DE ARQUIVOS PARA EXPORTAO........................... CONSIDERAES SOBRE A ABORDAGEM DAORE.................................... 4.3.1 COM RELAO AOS OBJETIVOS P ROPOSTOS............................. 4.3.2 USO NA REQUISITE E NO PROJETO DISEN................................. 4.3.3 DIFERENAS COM AS ABORDAGENS ESTUDADAS...................... RESUMO DO CAPTULO............................................................................. 90 91 91 98 100 102 103 104 105 107 108 109 109 110 111 111 113 114 114 115 116 118 129 129 139 139 147 154 157 158 158 159 161 161 162 171 176 177 177 178 179 180 182 189
4.3
4.4 5.
EXPERIMENTAO: CONTROLE DE EVENTOS....................................... 5.1 OBJETIVOS............................................................................................... 5.2 A ESCOLHA DA FERRAMENTA DE IMPLEMENTAO................................. 5.3 O SISTEMA PROPOSTO.............................................................................. 5.4 FASE 1 - IDENTIFICANDO OS REQUISITOS ................................................ 5.5 FASE 2 CONSTRUINDO O LXICO........................................................... 5.5.1 ANALISANDO INTERDEPENDNCIAS E RESOLVENDO CONFLITOS 5.5.2 CONSTRUINDO OS CENRIOS..................................................... 5.5.3 ANALISANDO OS CENRIOS....................................................... 5.6 FASE 3 - DEFINIO DE ASPECTOS CANDIDATOS..................................... 5.7 FASE 4 - MAPEAMENTO DE ONTOLOGIAS................................................. 5.8 GERAO DE ARQUIVOS PARA EXPORTAO.......................................... 5.9 RESUMO DO CAPITULO............................................................................. A FERRAMENTA REQUISITE E A ABORDAGEM DAORE....................... 6.1 SITUAO ATUAL.................................................................................... 6.1.1 MENU P RINCIPAL DA REQUISITE 6.2 SITUAO FUTURA................................................................................... 6.2.1 PROJETO DISEN........................................................................ 6.2.2 MUDANAS PREVISTAS NA REQUISITE...................................... 6.2.3 ANLISE DO IMPACTO DAS MUDANAS..................................... 6.3 RESUMO DO CAPTULO............................................................................. CONCLUSO.................................................................................................... 7.1 CONTRIBUIES....................................................................................... 7.2 LIMITAES E TRABALHOS FUTUROS...................................................... 7.3 CONSIDERAES FINAIS........................................................................... 7.4 TRABALHOS SUBMETIDOS........................................................................
REFERNCIAS BILBIOGRFICAS................................................................ ANEXOS............................................................................................................
xvi
1. Introduo
CAPTULO
1
INTRODUO
The best preparation for good work tomorrow is to do good work today. Elbert Hubbard
Nes te c ap tulo apres entamos uma vis o gera l da propos ta de dis s erta o. Inic ia lmente, des c revemos o c ontexto no qual es te traba lho de pes quis a s e ins ere. A s eguir, dis c utimos qual o problema que pretendemos res olver e qua is os objet ivos e f ina lidades da pesquis a, por fim apres enta mos a metodologia de pes quis a que foi adotada, delimit amos o es copo da propos ta de diss erta o e desc revemos a es trutura dos c ap tulos des te trabalho.
1 .1 Co nte xto
O processo de desenvolvimento de sistemas de informao sofreu uma quebra de paradigma com o surgimento da orientao a objetos na dcada de 80 (SHAELER & MELLOR, 1 9 90). At ento, 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 orientao a objetos no eram fceis de s e incorporar ao cotidiano, mesmo que os defensores da orientao a objetos afirmassem que a orientao a objetos uma coisa natural, pois o mundo orientado a objetos
1. Introduo
(www.forumweb.com.br/artigos/artigos.php? action=file&id=535). Muitas vezes, estas dificuldades na assimilao dos conceitos se deviam formao acadmica, 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 Orientao a Aspectos AOSD. Esta abordagem, em parte, segue os conceitos de (DIJKSTRA, 1976), q u e apresenta o princpio da separao de concerns1 , onde para superar a complexidade, deve-se resolver um concern importante por vez. Em engenharia de software, esse princpio est relacionado modularizao e decomposio 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 separao de concerns pode oferecer muitos benefcios cruciais (DIJKSTRA, 1976) (TARR, 1999). Ela oferece suporte a uma melhor manutenibilidade com alteraes aditivas, em vez de evasivas, melhor compreenso e reduo da complexidade, melhor reusabilidade e uma integrao de componentes simplificada. Para (ELRAD et al., 2001 apud SOUZA, 2004), assim como o paradigma orientado a objetos (POO) no descarta as idias de dados e operaes do paradigma estrutural, o paradigma orientado a aspectos (POA) no rejeita a tecnologia existente. O paradigma orientado a aspectos complementa o paradigma orientado a objetos a fim de auxiliar na separao daquelas preocupaes que o POO manipula deselegantemente (no possuindo recursos para fazer tal tarefa, necessitando de outras formas que tornam o cdigo mais difcil de entender e manutenir). Para isso, o paradigma orientado a aspectos prov mecanismos para localizar e compor os crosscutting concerns 2 (ou aspectos) com as unidades que eles afetam de maneira no invasiva, ou seja, evitando que fiquem explicitamente espalhados nos artefatos de software ou misturados com as preocupaes especficas 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 orientao a
Um concern pode ser definido como: questo, caracterstica ou preocupao. Porm, neste trabalho utilizaremos o termo em ingls. 2 Crosscutting concerns podem ser traduzidos como preocupaes ou caractersticas transversais. Em Piveta (2004) foi proposto que se utilizasse o termo concerns transversais, porm, neste trabalho, utilizaremos o termo em ingls.
1. Introduo
objetos h vinte anos atrs: os conceitos bsicos esto se formando e um grupo crescente de pesquisadores est usando esses conceitos em seus trabalhos sobre orientao a aspectos. As pesquisas realizadas em Early Aspects tm evoludo muito desde 2002 (RASHID et al, 2002). Por conseqncia, vrias abordagens tm se preocupado com a identificao 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 incio na orientao no aspectos e foram adaptadas e desenvolvidas a fim de se moldar ao novo paradigma da orientao 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 esto em desenvolvimento, mesmo porque, a abordagem de aspectos no chega a ser uma quebra de paradigmas, mas sim uma extenso 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 Distribudos (GESSD), desenvolvem vrios trabalhos relacionados Metodologia de Desenvolvimento de Software Distribudo MDSODI (GRAVENA, 2000) (HUZITA, 1999) . A MDSODI uma metodologia de desenvolvimento de software que oferece suporte especificao de alguns aspectos relacionados a sistemas distribudos desde as fases iniciais de projeto. A notao desta metodologia baseia-se na Unified Modeling Language UML (UML, 2006), mas adota tambm algumas extenses para a representao de sistemas distribudos. Dessa forma possvel abordar de forma clara os aspectos relacionados distribuio 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 cenrio onde sero utilizadas vrias ferramentas de apoio ao desenvolvimento de software cada qual criando e, possibilitando a manuteno necessria dos vrios artefatos relativos s diversas fases do processo. Estas ferramentas podero ter sido criadas especialmente para esta metodologia, ou ento serem ferramentas j existentes no mercado, produzidas por terceiros, cada uma com sua especialidade e potencialidade. Na mesma universidade, existe tambm o projeto de um ambiente distribudo de desenvolvimento de software, denominado Distributed Software Engineering Environment -
1. Introduo
DiSEN (PASCUTTI, 2002) (HUZITA,2004). O ambiente DiSEN foi concebido com vistas utilizao da metodologia MDSODI, enquanto que na sua arquitetura, pode-se observar que o mesmo oferece suporte a agentes. Entende-se, que neste ambiente, estaro sendo utilizadas vrias 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 preocupao com o gerenciamento de requisitos surgiu com a elaborao de uma ferramenta prpria a REQUISITE (BATISTA, 2003). Esta ferramenta foi desenvolvida baseada nos conceitos de orientao a objetos, seguindo ainda a metodologia MDSODI para ambientes distribudos, porm no considera os crosscutting concerns, tanto em nvel de desenvolvimento da ferramenta em si como em nvel de projeto dos requisitos inseridos. A elaborao de uma nova abordagem que contemple a identificao e composio dos crosscutting concerns e que esteja inserida no contexto da metodologia MDSODI permitir a atualizao dos projetos a serem desenvolvidos e os que esto atualmente sendo desenvolvidos, como o projeto do ambiente DiSEN e suas ferramentas de apoio.
1 .2 P ro ble ma
As motivaes para o surgimento do paradigma orientado a aspectos originaramse, principalmente, a partir de problemas encontrados na codificao de sistemas. Por isso, a maior parte da pesquisa nessa rea tem sido focada nas atividades orientadas implementao. Atualmente, a orientao a aspectos vem sendo utilizada, q u a s e que exclusivamente, na codificao de sistemas atravs 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 utilizao dos fundamentos e prticas desse paradigma para as atividades iniciais do ciclo de desenvolvimento (SOUZA, 2004). Algumas das razes que impulsionam essa rea de pesquisa so: Antecipar a identificao e a modelagem de aspectos; Antecipar o raciocnio sobre quais unidades devem ser afetadas por um aspecto e como a composio entre o aspecto e as unidades afetadas por ele deve ser realizada; Permitir que os benefcios da utilizao do paradigma orientado a aspectos sejam obtidos ao longo de todo processo de desenvolvimento e no apenas nos artefatos de implementao;
1. Introduo
Possibilitar que o entendimento de um sistema implementado com uma linguagem orientada a aspectos possa ser obtido atravs de modelos de anlise e projeto, ao invs de exigir que ele dependa da anlise do cdigo do sistema. Desde 2002, algumas abordagens iniciais vm sendo propostas nesse sentido.
Alguns trabalhos j se preocupam com outras fases do desenvolvimento, desde requisitos at a implementao, (SOUZA, 2004) (JACOBSON & NG, 2005) (CLARKE & BANIASSAD, 2005). Porm, todos os trabalhos pesquisados no possuem uma maneira clara e objetiva de tratar alguns problemas relacionados fase de requisitos. Alguns problemas gerais encontrados foram: A identificao e tratamento de requisitos organizacionais; A identificao de crosscutting concerns (sendo estes funcionais, no-funcionais ou at mesmo organizacionais); Representao grfica do modelo, em muitos casos o modelo no adequado ou a ferramenta para tal no est disponvel, como podemos observar no Captulo 3, onde realizamos um estudo comparativo das abordagens existentes; e Em algumas abordagens, a representao dos requisitos no funcionais (RNF) (CHUNG et al., 2000) se confunde com caractersticas adicionais do sistema, como no trabalho de Jacobson & Ng (2005). Adicionalmente podemos citar alguns problemas especficos ligados ao nosso projeto no ambiente DISEN: Insero no contexto da metodologia MDSODI; Exportao de modelos no padro XML, usando XML 3 Schema para definir padres a serem utilizados. Estes modelos englobam: Lxico Extendido da Linguagem4 (LEL), aspectos candidatos5 , cenrios6 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 relao a outras. Esse fato foi a principal motivao para o desenvolvimento desta proposta de
3 4
Uma definio de XML Schema e seus conceitos principais podem ser encontrados em XML (2006). LEL Lxico Extendido da Linguagem (Language Extended Lexicon), tcnica que auxilia a descrio de cenrios utilizando linguagem natural encontramos tambm o termo LAL (Lxico Ampliado da Linguagem) que significa a mesma coisa (Leite, 1997) 5 Veremos os conceitos de aspectos candidatos no Captulo 3. 6 Conceitos de cenrios e sua relao com o LEL podem ser encontrados em Leite (1997). 7 Conceitos de ontologias pode ser encontradas em Breitman (2005).
1. Introduo
dissertao (veremos mais no Captulo 3, item 3.5 - Anlise Comparativa das Abordagens em AORE).
1 .3 Co nt ribui e s
A principal contribuio deste trabalho integrar a metodologia MDSODI ao desenvolvimento de software orientado a aspectos. Esta contribuio baseada na tcnica do LEL utilizada pelo ambiente DISEN na elicitao dos requisitos atravs da ferramenta Requisite. Com o desenvolvimento de uma nova abordagem que possa integrar o LEL na orientao a aspectos, de forma a facilitar a identificao dos aspectos candidatos nas fases iniciais do processo de desenvolvimento, ir contribuir para aumentar o reuso de componentes especificados.
1 .4 Obje t iv o s
O objetivo geral desta dissertao apresentar uma nova abordagem de orientao a aspectos para a fase de engenharia de requisitos, que se utilize do LEL, para que possa facilitar a identificao e a separao de concerns nos projetos elaborados com base na metodologia MDSODI. A partir desse objetivo geral, definimos os seguintes objetivos especficos: Compreender os fundamentos do Desenvolvimento de Sistemas baseado na Orientao a Aspectos nas fases iniciais do processo de desenvolvimento; Propor uma nova abordagem atravs da anlise e seleo de pontos de vantagens oferecidas pelas abordagens existentes, permitindo uma abordagem mais flexvel que possibilite o suporte tanto na adaptao de projetos existentes (por se utilizar do LEL) quanto para novos projetos; e Realizar a validao utilizando a abordagem proposta atravs da experimentao, onde o projeto a ser desenvolvido ser o mesmo apresentado pela ferramenta REQUISITE para que se possa avaliar o impacto das mudanas propostas na ferramenta e no ambiente DISEN.
1. Introduo
1 .5 J ust if ic a tiv a
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 evoluo, no uma revoluo, em relao ao paradigma orientado a objetos e pode ser usado para melhorar tcnicas existentes. A quebra de paradigmas sempre foi um grande problema na rea de desenvolvimento de sistemas, em particular na dcada de 80 com o surgimento da orientao a objetos. Podemos dizer que foi uma grande revoluo, pois apresentava conceitos at ento desconhecidos e completamente diferentes dos usados na poca. A orientao a aspectos, por outro lado, no apresenta conceitos to diferentes assim, pois ela apenas agrega alguns conceitos abordagens que j existem. Desde o seu surgimento, no fim da dcada de 90, voltada apenas para a implementao, um exemplo disso, uma vez que adicionava construes e mecanismos especficos para o tratamento de aspectos em linguagens de programao, como AspectJ (KICZALES., 2001), que estende a linguagem orientada a objetos Java (GOSLING et al., 2000). Atualmente, as abordagens existentes em orientao a aspectos possuem algumas vantagens, como: (i) (ii) Descrio detalhada das fases principais do desenvolvimento; Caractersticas prprias definidas pelo tipo de abordagem considerada; Porm, todas possuem uma caracterstica negativa: no oferece a p o i o identificao de aspectos. Pelos motivos acima descritos, a direo que escolhemos para alcanar o objetivo geral deste trabalho foi o de propor u m a nova abordagem que facilite a identificao de aspectos nas fases iniciais do processo de desenvolvimento utilizando a metodologia MDSODI para sistemas distribudos, que estejam inseridas no contexto de cenrios utilizando o LEL.
1 .6 Esc o po da D isse rta o

Conforme mencionado anteriormente, para alcanar o objetivo geral desta dissertao, decidimos adaptar algumas caractersticas das abordagens existentes para as fases iniciais do processo de desenvolvimento.
8
Mas no se limita ao paradigma orientado a objetos, podendo ser usado tambm em conjunto com outros paradigmas como o estruturado e o funcional (CONSTANTINIDES & HASSOUN, 2002).
1. Introduo
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, implementao e testes, sendo um trabalho a ser feito futuramente.
1 .7 Me to do lo g ia de De se nv o lv ime nto da P e squisa

A pesquisa em Engenharia de Software pode ser conduzida atravs de quatro mtodos: o cientfico, o de engenharia, o experimental e o analtico (WOHLIN, 2000 apud TRAVASSOS, 2002). O mtodo cientfico foca na observao de um ambiente e na tentativa de extrair dele algum modelo ou teoria que possa explicar o fenmeno estudado. O mtodo de engenharia, por sua vez, baseado na observao de solues existentes, na identificao de problemas nessas solues e na sugesto de abordagens para melhorar as solues analisadas. J o mtodo experimental pretende fornecer um modelo novo para soluo de um problema e tenta estudar o impacto desse modelo. Por fim, o mtodo analtico oferece uma base analtica (ou matemtica) para o desenvolvimento de modelos. Este trabalho de pesquisa seguiu o mtodo de engenharia (baseado na Figura 1.1).
1. Introduo
1 - Reviso Bibliogrfica
- AOSD
-MDSODI, DISEN e REQUISITE
- Abordagens existentes em
AORE
2 - Anlise das Abordagens - Anlise Comparativa; - Definio de pontos principais a serem considerados
3 Exame de Qualificao
-Apresentao da proposta de qualificao 4 - Elaborao da Nova Abordagem -Nova abordagem a partir dos pontos considerados - atravs da experimentao
5 - Aplicao na nova Abordagem
6 - Validao
-Anlise do impacto das mudanas no ambiente DISEN e na ferramenta REQUISITE - Apresentao da dissertao
7 - Apresentao
FIGURA 1.1 ESTRUTURA DA PESQUISA SEGUIDA.
Na Figura 1.1 temos a estrutura de pesquisa que foi seguida: 1. Inicialmente foi feita u m a reviso bibliogrfica sobre os conceitos de AOSD, a metodologia MDSODI, o ambiente DISEN e a ferramenta REQUISITE. Aps isso, foi elaborado u m estudo sobre algumas
abordagens existentes par a 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. Introduo
10
2. Nesta fase foi realizada uma anlise 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 qualificao para o mestrado; 4. Baseado nos pontos considerados no passo 2 foi elaborada a nova abordagem de forma a apresentar caractersticas identificadas em algumas das abordagens estudadas, alm de possuir caractersticas prprias; 5. Aplicao da nova abordagem em um estudo de caso para validar a mesma. Este estudo de caso foi o mesmo realizado por ocasio da validao da ferramenta REQUISITE, a fim de se obter um comparativo de avaliao utilizando duas abordagens diferentes; 6. Anlise das mudanas para avaliar o impacto na ferramenta REQUISITE e no projeto DISEN, com o objetivo de sugerir mudanas e pontos crticos para a validao da nova abordagem, ou seja, o quanto esta mudana foi benfica para o projeto; e 7. Apresentao do trabalho.
1 .8 O rg a niza o da D isse rta o

Alm deste captulo introdutrio e de um glossrio e um anexo que inclumos no final da dissertao, este trabalho composto pelos seguintes captulos: Captulo 2: apresenta uma viso geral do Desenvolvimento Orientado a Aspectos e descreve algumas abordagens utilizadas para a fase de Requisitos. Ao final do captulo apresentado um comparativo entre as abordagens. Este estudo comparativo foi utilizado como base da confeco da nova abordagem; Captulo 3: apresenta uma viso geral sobre a metodologia MDSODI, o ambiente DiSEN e a ferramenta REQUISITE e como se relacionam; Captulo 4: detalha a nova abordagem, descrevendo em cada fase o que dever ser feito; Captulo 5: descreve a utilizao da abordagem apresentada no Captulo 4 em uma experimentao. O objetivo principal propiciar a validao da nova abordagem, de maneira que se possa avaliar o impacto sobre a ferramenta REQUISITE e o projeto DiSEN;
1. Introduo
11
Captulo 6: apresenta o impacto da abordagem DAORE na ferramenta Requisite, suas principais implicaes, anlises e comparaes; e
Captulo 7: apresenta as concluses, enumera as contribuies e prope trabalhos futuros.
2.Desenvolvimento de Software Orientado a Aspectos
12
CAPTULO
2
DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS
O que sabemos uma gota, o que ignoramos um oceano. Isaac Newton
O des envolvimento de s oftware te m s ido a lvo de es tudos (CHITCHYAN et a l, 2005b) (SILVA, 2004) a f im de gar ant ir a qualidade do produto fina l, ou s e ja, o s oftware e m s i, e do prprio proc esso de des envolvimento que o definiu. Is to tem ocorrido des de meados da dc ada de 70 c om o des envolvimento es truturado, s endo a An lis e Es truturada de Sis temas oriunda da programa o es truturada. O Des envolvimento de Software Or ie ntado a As pec tos (AOSD) advindo da programa o orient ada a as pec tos , ass im c omo foi na poc a do des envolvime nto es truturado de s is temas . As tc nic as exis tentes de AOSD provm uma forma s is temt ic a de ident if ic ar, modular iz ar, repres entar e c ompor os crosscutting concerns (propriedades trans vers ais ) como: s eguran a, mobilidade e regras de tempo real (CHITCHYAN et a l., 2005).
13
Em 1999, e m um c ongres s o de Engenhar ia de Requis itos em Lymer ic k Ir e land, fo i ut ilizado pela prime ira vez o ter mo Aspect-oriented Requirements Engineering ou AORE (GRUNDY,1999), demons trando o interes s e e a preoc upa o em tratar es tes cros scutting concerns j na f as e de requis itos . Em 2002, em Es s en-Ale manha, igua lme nte no c ongres so de Engenhar ia de Requis itos o termo Early Aspects (RASHID et a l, 2002) fo i us ado pela pr ime ira ve z. Early Aspects tem c omo foc o princ ipa l a ger nc ia das propriedades trans vers a is nos es tgios inic ia is do des envolvimento, e nglobando desde a engenha r ia de requis itos at o design de arquite tura. Nes te c ap tulo apres entado uma vis o gera l dos princ ipa is c onc eitos do des envolvime nto de software orie ntado a as pec tos e algumas abordagens exis tent es em AOSD. Inic ia lmente, des c reves e os conc eitos bs ic os da orienta o a as pec tos , c omo a s epara o de propriedades , por exemplo. Em s eguida, deta lhado as motiva es para o s urgime nto des s e paradigma de des envolvimento, des c revendo os problemas que e le s e prope a s oluc ionar e a lgumas abordagens exis tentes em AORE. Por fim, rea liz ada uma c ompara o entre as abordagens apres entadas , enfat izando s eus pontos fortes e fracos nas c ons idera es fina is , a qual s er o ponto de partida para o prximo c ap tulo.
2 .1 Co nc e ito s Ge ra is de De se nv o lv ime nto O rie nta do a As pe c to s (AOSD)

Alguns conceitos relacionados AOSD so muito importantes para o perfeito entendimento deste paradigma, pois so a partir destes que todo o processo baseado. Assim, veremos alguns destes conceitos a seguir.
14
2 .1 .1 Co nc e ito de a spe c to s, c onc ern e cr oss cutting con ce rn

Encontramos algumas definies de aspectos na literatura pesquisada, que se segue: Segundo Jr (2003) aspectos so representaes de concerns que atravessam as representaes de outros concerns. Para Clarke & Baniassad (2004, 2005) os aspectos so comportamentos que esto misturados e espalhados atravs do sistema e um tipo particular de concern. Brito & Moreira (2003) definem um concern como sendo uma questo 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 caracterstica do sistema ou do domnio 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 mdulo ou em mltiplos mdulos do sistema. Para Chitchyan et al. (2005a) o termo crosscutting concerns se refere a fatores de qualidade ou funcionalidades do software que no podem ser eficientemente modularizados usando tcnicas 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 no funcional (YU et al, 2004) e que um crosscutting concern uma propriedade transversal, ou seja, um requisito (ou propriedade) que est transversal em relao a outros requisitos um forte candidato a ser um aspecto. Existem vrios exemplos de comportamentos que podem ser citados como aspectos e que possuem este comportamento ou funcionalidade de precisar ser carregada em diferentes mdulos de um cdigo orientado a objeto, como segurana, persistncia e sincronizao, entre outros. Atualmente h uma preocupao crescente em conseguir identificar aspectos nas fases iniciais do processo de desenvolvimento, sendo alvo de estudos comparativos de
15
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 anlise de requisitos, anlise de domnio e a fase de projeto da arquitetura. As tcnicas de AOSD provm uma maneira sistemtica de identificar, modularizar, representar e compor os crosscutting concerns, ou seja, separao e composio de propriedades (CHITCHYAN et al, 2005a). A seguir descrito estes dois conceitos, que so os pilares da orientao a aspectos.
2 .1 .2 Se pa ra o de P ro prie da de s
Produzir software com qualidade sempre foi um dos objetivos de todo o desenvolvedor de software. P ressman (2005) alega que alm de produzir software de qualidade deve-se tentar faz- lo em um menor espao de tempo possvel, sendo esse um dos principais objetivos da Engenharia de Software. Para alcanar tal objetivo, diversas abordagens foram propostas ao longo dos anos: Anlise Estruturada de Sistemas (GANE & SARSON, 1977), Anlise Essencial de Sistemas (MCMENAMIN & PALMER, 1984), Anlise 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 princpios que devem ser aplicados ao longo do processo de desenvolvimento e nos artefatos de software: separao de propriedades, modularidade, rigor e formalidade, incrementalidade, abstrao, generalidade e antecipao de mudanas. O objetivo da separao de propriedades identificar e modularizar as partes do software que so relevantes para um conceito em particular, meta ou propsito (BRITO & MOREIRA, 2003).
16
Com isso, este princpio permite que se reduza o raciocnio a uma quantidade factvel (DIJKSTRA, 1976). Esse princpio estabelece que um problema possa s e r decomposto em unidades menores, claramente separadas, de maneira que cada uma delas represente uma nica preocupao (AKSIT et al. apud SOUZA, 2004). A idia bsica manipular com uma preocupao do sistema de cada vez, ou seja, o velho e bom dividir para conquistar. Como conseqncia, a aplicao desse princpio possibilita: Diminuir a complexidade do desenvolvimento de software, concentrandose em diferentes preocupaes separadamente; Raciocinar sobre diferentes preocupaes de maneira relativamente independente; Facilitar a insero/remoo de preocupaes na aplicao; Dividir esforos 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 separao de propriedades, elas tendem a ser similares (forte coeso) e a dependncia entre os artefatos minimizada (fraco acoplamento). Conseqentemente, mudanas 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 compreenso, evoluo, adaptao, customizao e reuso dos artefatos de software. Para implementar este princpio o engenheiro de software dever se basear no paradigma de programao adotado (objetos, estruturado ou aspectos). De maneira geral, os mtodos para separao de propriedades envolvem as seguintes atividades (AKSIT et al. 2001): Identificao d e propriedades: seleo de propriedades que o sistema vai incluir; Representao de propriedades separadamente: especificao de propriedades em unidades ou num conjunto de unidades que concretizam a realizao de cada uma das propriedades; e
17
Composio de propriedades: integrao de unidades separadas a fim de dar a elas alguma coerncia para formar o conjunto do sistema.
As abordagens tradicionais de desenvolvimento de software (orientao a objetos e
mtodos estruturados) f o ram criadas com este princpio geral em mente. Entretanto, elas possuem limitaes no tratamento dos requisitos no-funcionais. Assim, no consideram a natureza de transversal destas propriedades. Para tentar solucionar essas limitaes, foram propostas algumas abordagens na literatura, tais como: Programao Adaptativa
(LIEBERHERR, 1996), Filtros de Composio (BERGMANS & AKSIT, 2001; BERGMANS et al., 2001), Separao Multidimensional de Preocupaes (TARR et al., 1999; OSSHER & TARR, 2000) e Programao Orientada a Aspectos (KICZALES et al., 1997). Essas propostas pertencem a uma rea de pesquisa denominada de Separao Avanada de Preocupaes (Advanced Separation of Concerns). Um modelo genrico para tratar a separao avanada 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.
o termo preocupaes utilizada na traduo em alguns artigos, porm iremos utilizar propriedades.
18
FIGURA 2.1 MODELO DE S EPARAO AVANADA DE PROPRIEDADES. ADAPTADO DE (BRITO & MOREIRA, 2003).
A seguir segue-se uma breve descrio das tarefas a serem realizadas na Figura 2.1:
Tarefa 1 Identificar Concerns 2 a identificao de propriedades uma tarefa extremamente importante, pois acompanhada por um entendimento completo e exaustivo do sistema por meio da anlise da documentao e qualquer outra informao fornecida pelos stakeholders3 do sistema. Segundo Brito &Moreira (2003) ainda uma atividade dependente principalmente da experincia do engenheiro de software.
Tarefa 2 Especificar Concerns esta tarefa subdividida em trs sub-tarefas: aplicar a abordagem que melhor especifica cada propriedade; identificar
O termo concern utilizado por Brito & Moreira (2003). Assim, ser utilizado apenas nos ttulos das tarefas explicitadas por eles. 3 Stakeholder pode ser qualquer pessoa que tem uma influncia direta ou indireta no projeto (BRITO & MOREIRA, 2003).
19
contribuies 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 tcnica para a especificao de requisitos. Em certos casos, a escolha deve ser feita durante a Tarefa 1, especialmente se uma tcnica particular foi usada para auxiliar o processo de elicitao. Se for assim, podemos construir qualquer modelo ou outra documentao proposta por estas tcnicas. Tarefa 2.2 Identificar contribuies entre concerns o relacionamento de contribuio entre duas propriedades define a maneira pela qual uma propriedade afeta o outro. Esta contribuio pode ser colaborativa (ou positiva, quando auxilia o propriedade afetada) e sua representao feita por um +, ou perigosa (ou negativa, obstruindo a propriedade afetada) e sua representao feita por um -. Tarefa 2.3 Identificar prioridades e inter-relacionamentos uma prioridade proporciona um grau de importncia a uma propriedade no sistema. A prioridade da propriedade um contexto de dependncia, por exemplo, uma m e s m a propriedade pode ser classificada com diferentes prioridades pelo stakeholder dependendo do domnio de negcio. 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 subtarefas. Tarefa 4.1 Identificar match points Identificar os pontos onde a composio ser realizada. Um match point indica qual propriedade transversal deve ser composta com uma dada propriedade. Tarefa 4.2 Identificar conflitos identificar as situaes de conflito entre propriedades. Para um dado match point precisamos analisar se as propriedades transversais envolvidas contribuem negativamente para outras quaisquer. Se contriburem positivamente no h problema.
20
Tarefa 4.3 Identificar concerns dominantes Esta sub-tarefa ajuda a resolver os conflitos identificados na tarefa anterior e baseado nas prioridades atribudas. Se a prioridade atribuda a cada propriedade diferente, o problema no to difcil de resolver, e a propriedade dominante aquele com a maior prioridade. Entretanto, se no mnimo duas propriedades transversais possuem a mesma prioridade, um trade-off4 devem ser negociado entre os usurios. A identificao da propriedade dominante importante para guiar a regra de composio.
Tarefa 4.4 Definindo regras de composio a regra de composio 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 iro depender da linguagem a ser utilizada. Esta regra expressa a ordem seqencial 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 juno.
2 .1 .3 Co mpo s i o de P rop ri ed a d es
Na Figura 2.1 a composio de propriedades realizada atravs da Tarefa 4 ( e suas sub-tarefas), como explicado anteriormente. Jacobson (2005) argumenta que a composio de aspectos, principalmente se for feita em um nvel mais alto de modelos de pontos de juno no uma tarefa trivial. Realizar a composio de aspectos dinamicamente tem seus prprios desafios, tornando esta tarefa complicada na fase de programao. Porm, isto no implica que a composio em nvel de requisitos seja trivial. Sem dvida, so problemas diferentes, mas possuem desafios em ambas as situaes. Na programao pelo menos um modelo estruturado do sistema j est definido (JACOBSON, 2005). J na fase de requisitos, a situao diferente, pois requisitos tendem a estar em pedaos de textos os quais, geralmente, so difceis de serem interpretados e possuem informaes ambguas e incompletas (muitas das vezes).
Trade-off no pode ser traduzido literalmente pois perder o sentido, porm neste contexto se refere a um ponto de equilbrio ou uma troca, a fim de achar um ponto neutro.
21
Assim o trabalho de especificao de regras de composio (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 composio de propriedades transversais com as unidades de decomposio do sistema que elas afetam (tambm denominadas de unidades base). Para que um aspecto seja combinado com a(s) unidade(s) que ele afeta, so necessrias algumas informaes: (a) Ponto(s) de juno: indica em que ponto(s) na especificao da(s) unidade(s) base o comportamento do aspecto deve ser includo (BRITO & MOREIRA, 2003); (b) Regra de composio: expressa a ordem seqencial 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 juno. As regras de composio mais comuns so: antes, depois, e ao invs de; Exemplificando: quando dito que o aspecto de autenticao de senha deve ser aplicado antes da execuo de transaes bancrias, o termo antes corresponde a uma regra de composio e a sentena execuo de transaes bancrias corresponde ao ponto de juno (SOUZA, 2004) Existem quatro possibilidades de especificar a composio entre um aspecto e unidades base (KERSTEN & MURPHY, 1999): Fechada: o aspecto e a unidade base no tm conhecimento sobre a existncia um do outro, ou seja, eles no se referenciam diretamente; Aberta: aspecto e a unidade base tm conhecimento sobre a existncia 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.
22
Segundo (SOUZA, 2004) a associao do tipo fechada a preferencial, visto que permite a independncia tanto das unidades base quanto do aspecto, promovendo, ento, melhor potencial para que os artefatos envolvidos possuam qualidades como reusabilidade, compreensibilidade e manutenibilidade. A associao do tipo aberta deve ser evitada, pois resulta em acoplamento entre os dois tipos de artefatos e, conseqentemente, compromete o alcance da separao de propriedades e seus benefcios. Por sua vez, as associaes do tipo dirigida ao componente e dirigida ao aspecto, promovem as qualidades j citadas apenas com relao unidade base e ao aspecto, respectivamente. Ainda segundo (SOUZA, 2004) os tipos de associaes mais comuns nas abordagens orientadas a aspectos so as fechadas e dirigidas ao componente.
2 .1 .4 A P ro g ra ma o O rie nta da a A s pe c to s e a Ling ua g e m As pe c tJ

O termo programao orientada a aspectos atribudo ao grupo de pesquisa da Xerox PARC liderado por Gregor Kiczales e corresponde a uma tcnica de programao que possibilita a separao de preocupaes transversais na implementao de sistemas (KICZALES et al., 1997). Essa abordagem denomina de maneira distinta dois tipos de preocupaes: as que conseguem ser adequadamente modularizadas pelos paradigmas estruturado ou orientado a objetos so chamadas de componentes; e aquelas que no conseguem, ou seja, as preocupaes transversais, so denominadas de aspectos (KICZALES et al., 1997). Na Programao Orientada a Aspectos, assume-se que existe uma decomposio dominante do sistema (ex: em classes ou mdulos) para os componentes, e que os aspectos representam outra unidade de decomposio do sistema. Dessa maneira, componentes so implementados numa linguagem procedural ou orientada a objetos, enquanto aspectos so codificados em uma linguagem especialmente designada para esse propsito (SOUZA, 2004). Linguagens orientadas a aspectos utilizam cinco elementos para permitir a modularizao de preocupaes transversais (ELRAD et al., 2001):
23
(i) um modelo de pontos de juno descrevendo os possveis pontos onde o comportamento do aspecto pode ser adicionado; (ii) um meio de identificar esses pontos de juno; (iii) um meio de especificar o comportamento adicional nesses pontos; (iv) unidades que encapsulam a especificao dos pontos de juno 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 Programao Orientada a Aspectos, propriedades transversais so encapsuladas em unidades denominadas aspectos, nas quais so especificados os pontos de execuo 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 combinao de aspectos e componentes, num processo denominado de weaving.
Componentes Classe Combinador de aspectos (weaver) Aspecto Aspectos Sistema

FIGURA 2.2 - PROCESSO DE COMBINAO DE ASPECTOS E CLASSES PARA GERAR O SISTEMA. FONTE: (SOUZA, 2004)
A linguagem AspectJ (KICZALES et al., 2001) um superconjunto ou uma extenso da linguagem Java5 (GOSLING et al., 2000) para ser usado na Programao Orientada a Aspectos. Em uma aplicao 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.
24
componentes so implementados usando a sintaxe padro de Java, e os aspectos so implementados usando uma sintaxe especfica de AspectJ. Essa linguagem utiliza um processador de aspectos denominado de weaver para combinar o cdigo do aspecto com o cdigo dos componentes e conseqentemente produzir o sistema executvel. Aps a compilao e o processo de weaving, o cdigo objeto gerado pode ser executado em qualquer mquina virtual Java. Em AspectJ, o cdigo referente a uma propriedade transversal especificado numa unidade de codificao denominada aspect (veja Figura 3.3). Dentro da unidade do tipo aspect, o cdigo relacionado propriedade transversal utiliza construtores lingsticos especiais: o construtor pointcut utilizado para capturar ou identificar pontos de juno no fluxo do programa sobre os quais o aspecto atua. Exemplos de possveis pontos de juno incluem inicializao de objetos, chamadas de mtodos e acesso a campos;
advices so blocos de cdigo no quais devem ser definidos as regras de composio e o comportamento a ser executado pelo aspecto. Para determinar as regras de composio nos pontos de juno identificados, utilizam-se as regras de composio before, after e around. Essas regras i n d i c a m q ue o comportamento do aspecto deve ser executado,
respectivamente, antes, aps, ou ao invs de cada ponto de juno definido pelo pointcut associado. inter-type declarations possibilita que classes presentes no sistema sejam modificadas estruturalmente: (i) acrescentando mtodos, atributos e classes internas; e (ii) alterando a hierarquia de herana de classes e interfaces.
25
Atributos Mtodos Pointcuts ou pontos de corte Advices ou informaes Declaraes intertype
Parte comum a classes
Construtores especficos de AspectJ
FIGURA 2.3 ESTRUTURA DE UMA ENTIDADE ASPECT EM ASPECTJ. ADAPTADO DE (SOUZA, 2004).
Conforme ilustra a Figura 2.3, alm dos construtores prprios de AspectJ, uma unidade do tipo aspect pode conter membros de dados e mtodos, assim como uma classe. A Figura 2.4 apresenta um exemplo de cdigo em AspectJ que implementa um aspecto de logging para rastrear a execuo de mtodos. A princpio, definido um ponto de juno loggedMethod (linha 3), incluindo todas as chamadas de mtodos. Entre a linha 5 e a 11 so definidos dois advices para que sejam exibidas mensagens imediatamente antes da execuo e imediatamente aps o retorno do ponto de juno.
1 2 3 4 5
6
public aspect Logging { Pointcut LoggedMethod(): call (* *(..)); Before(): loggedMethod() { System.out.println(--ANTES DA EXECUO DA CHAMADA DE UM MTODO --); } after(): loggedMethod() { System.out.println(--DEPOIS DO RETORNO DA CHAMADA DE UM MTODO --); } FIGURA 2.4 - EXEMPLO DE CDIGO EM ASPECTJ. ADAPTADO DE (SOUZA, 2004).
7 8 9 10 11 12 }
Para que se compreenda o processo de desenvolvimento de sistemas utilizando a orientao a aspectos preciso conhecer os conceitos de algumas das abordagens de desenvolvimento utilizadas na Fase de Requisitos.
26
3 .2 F a se de Re quis ito s
A abordagem da Engenharia de Requisitos Orientada a Aspectos (AORE), tem como objetivo o tratamento sistemtico e modular, na argumentao, composio e subseqente rastreamento das propriedades transversais funcionais e no funcionais atravs de uma adequada abstrao, representao e mecanismos de composio prprios para o domnio da engenharia de requisitos (CHITCHYAN et al, 2005a). A seguir sero apresentadas as principais abordagens existentes para esta fase, que serviro de ponto de partida para a definio da nova abordagem, a ser apresentada no presente trabalho.
2 .2 .1 A bo rda g e m V ie wpo int

A abordagem da Engenharia de Requisitos Orientada a Viewpoint considera a informao do problema relacionado a partir de vrios agentes ao ser estabelecido o que requerido para a resoluo de determinado problema, os quais podem ter perspectivas incompletas e igualmente vlidas (CHITCHYAN et al, 2005a). A combinao entre agentes e as vises dos agentes chamado de viewpoint. (CHITCHYAN et al, 2005b). Em (SOMMERVILLE & SAWYER, 1998) apresentado o PREView, sendo uma abordagem no orientada a aspectos, onde uma generalizao da noo de metas, que inclui tanto as metas organizacionais que restringem o sistema como o processo a ser analisado. Esta abordagem no identifica qualquer propriedade transversal separadamente: todas elas so tratadas como parte de um ponto de vista. Embora os pontos de vista ou viewpoints possam sobrepor e transpor as outras, esta tratado como questo de resoluo de inconsistncia, mais do que um problema de separao de propriedades. Em (RASHID et al 2002) esta abordagem recebeu o nome de AORE, porm 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 instanciao do modelo geral do processo de requisitos, conforme pode ser observado na Figura 3.5. Esta instanciao similar ao utilizado no PREview. Entretanto, no Arcade, seu objetivo est em modularizar e compor propriedades no nvel de requisitos e no apenas na produo de um documento de especificao de requisitos.
27
Podemos observar que a Figura 2.5 muito similar a Figura 2.1. Na verdade, a Figura 2.5 foi uma adaptao e refinamento desta ltima. Suas fases e descries so similares apresentada na Figura 2.1.
Identificar concerns
Identificar requisitos
Especificar concerns
Especificar requisitos
Revisar especificaes de requisitos
Relacionar concerns e requisitos
Identificar aspectos candidatos Definir regras de composio composio compor aspectos candidatos e requisitos
elaborar tabelas de contribuio Gerenciar conflitos atribuir medidas para aspectos conflitantes especificar dimenses do aspecto
Resolver conflitos
FIGURA 2.5 MODELO DE PROCESSO AORE. ADAPTADO DO (RASHID ET AL, 2003)
(RASHID et al, 2002) definem q u e , inicialmente, necessrio identificar requisitos funcionais e propriedades, porm a ordem no definida pelo modelo: ela
28
depender da interao entre os engenheiros e os usurios do sistema, mesmo porque esta atividade ainda uma atividade que depende da experincia do engenheiro de requisitos. Aps esta fase, na qual f o ram identificados os requisitos e propriedades pertinentes ao domnio 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 propriedades 1 propriedades 2 ... propriedades n X X R2 X .... Rn X X
Observando a matriz formada pela Tabela 2.1 podemos constatar quais propriedades cruzam com os mdulos encapsulados pelos requisitos dos stakeholders. Estas propriedades so 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 aps serem identificados os aspectos candidatos so necessrios detalhar as regras de composio. Estas regras operam na granularidade dos requisitos individualmente e, no apenas nos mdulos que as encapsulam. Assim possvel especificar como um requisito aspectual influencia ou restringe o comportamento de um conjunto de requisitos no aspectuais nos vrios mdulos. Ao mesmo tempo, aspectos trade-offs podem ser observados em uma granularidade menor. Isto exclui a necessidade de negociaes 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. Tambm facilita a identificao de conflitos individuais dos requisitos aspectuais com respeito a qual negociao deve ser cumprida e o equilbrio estabelecido.
29
A prxima atividade responsvel 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 clulas em branco significam que no tem contribuio Aps preencher esta tabela devemos atribuir pesos para os aspectos que contribuem negativamente com outro em relao ao conjunto de requisitos do usurio. Cada peso um nmero real em um intervalo de 0 a 1 e representa a prioridade de um aspecto em relao ao conjunto de requisitos dos stakeholders. Aps atribuir os pesos aos aspectos devem-se resolver os conflitos com os stakeholders, usando a priorizao acima descrita para auxiliar a comunicao. Por fim, deve-se especificar o impacto de aspectos candidatos em termos de duas dimenses: mapeamento e influncia. A dimenso de mapeamento especifica como cada aspecto candidato ser manipulado nos estgios seguintes do desenvolvimento. Nesta dimenso o aspecto candidato pode ser mapeado em uma funo, deciso arquitetural ou num aspecto. Por outro lado, a dimenso de influncia estabelece quais os pontos do ciclo de desenvolvimento que o aspecto candidato afetar. A tabela 2.3 mostra um exemplo de sada dessa atividade.

TABELA 2.3 EXEMPLO DE UMA ESPECIFICAO DA DIMENSO DO ASPECTO. FONTE: (RASHID ET AL, 2002).
30
Aspecto Candidato Compatibilidade Tempo de Resposta Restries Legais Corretude Segurana Disponibilidade
Influncia
Mapeamento
Especificao, arquitetura, design, evoluo Funo Arquitetura, design Especificao Especificao, design Arquitetura, design Arquitetura Aspecto Funo Funo Aspecto Deciso Aspecto
Sistema Multi- usurio Arquitetura, design
Por sua vez, Moreira et al. (2002), Araujo et al. (2002) e Brito & Moreira (2003) usam uma instncia simplificada do modelo AORE baseada em UML (BOOCH et al., 1999). S ouza ( 2004) detalha este trabalho como sendo uma extenso do processo anterior e Chitchyan et al ( 2005b) apresentam como sendo uma extenso da abordagem viewpoint e apenas cita os trabalhos. Porm, vamos tratar este trabalho em separado, pois apesar de se utilizar do modelo AORE detalhado anteriormente possui algumas caractersticas diferentes.
2 .2 .2 A bo rda g e m AO RE ut iliza ndo U ML

Esta abordagem teve incio em Moreira et al. (2002), Arajo et al. (2002) e Brito & Moreira (2002) e composta de trs atividades principais, descritas a seguir: a) Identificar concerns 6 - em (BRITO & MOREIRA, 2002) esta atividade limitada a identificar os requisitos do sistema e selecionar os requisitos de qualidade que so relevantes para o domnio da aplicao. No especifica como identificar os requisitos, especificam ainda que esta atividade deve identificar todas as propriedades do sistema, ou seja, os requisitos funcionais e no- funcionais. Os autores dizem ainda que diferentes tcnicas podem ser utilizadas para identificar os requisitos e particularmente escolheu a tcnica de casos de uso. Porm, salientam que a identificao de propriedades funcionais e no funcionais ir depender da
O termo concern foi utilizado apenas no ttulo da atividade, porm ser utilizado propriedade em outras oportunidades.
31
viso dos stakeholders em relao ao sistema e dinmica de comunicao entre os desenvolvedores e clientes. b) Especificar concerns e identificar q u a is d e l e s so 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 Descrio Focus
Nome do atributo de qualidade Descrio sucinta O atributo de qualidade pode afetar o sistema (produto final) ou o desenvolvimento do processo
Fonte
Fonte da informao (documentos, stakeholders)
Decomposio Os atributos de qualidade podem ser decompostos em outros mais simples. Quando todos (sub) atributos de qualidade so necessrios para obter o atributo de qualidade, temos um relacionamento AND, caso contrrio, temos um relacionamento Prioridade OR. Expressa a importncia do atributo de qualidade para os stakeholders. A prioridade pode ser MAX, HIGH, LOW e MIN. Obrigao Influencia Onde Pode ser opcional ou obrigatria. Atividades do processo afetadas pelos atributos de qualidade Lista dos atores influenciados pelos atributos de qualidade e uma lista de modelos (casos de uso, diagramas de seqncia) que necessitam do atributo de qualidade. Requisitos Contribuio Requisitos descrevendo o atributo de qualidade. Representa como o atributo de qualidade afeta outros atributos. A contribuio pode ser positiva (+) ou negativa (-).
32
b.3) propor um conjunto de modelos para representar a integrao de atributos de qualidade transversais e requisitos funcionais. Para Brito & M oreira (2003) esta atividade deve especificar propriedades e finalizar pela identificao dos aspectos candidatos. As propriedades funcionais so especificadas atravs de um conjunto de cenrios e diagramas de seqncia. As propriedades no funcionais atravs 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 NO FUNCIONAIS. FONTE: (BRITO & MOREIRA, 2003)
Nome Descrio Prioridade
Nome da propriedade no funcional Descrio sucinta Expressa a importncia da propriedade. A prioridade pode ser Muito Importante, importante, mdio, baixo e muito baixo.
Decomposio As propriedades podem ser decompostos em outros mais Onde simples. Lista de modelos e seus elementos (casos de uso, classes, diagramas de seqncia) que necessitam da propriedade Requisitos Contribuio Requisitos descrevendo a propriedade Representa a maneira como uma propriedade afeta outras propriedades. A contribuio pode ser positiva (+) ou negativa (-).
Brito & Moreira ( 2003) deixam claro que as informaes na tabela (Tabela 2.5) devem ser preenchidas gradativamente, pois parte de uma propriedade pode ser dependente da especificao de outra. Ambos os trabalhos deixam claro que a identificao de propriedades transversais d e v e s e r definida nas linhas Onde e Requisitos. Estas sero 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
33
sistema. Brito & Moreira (2002) especificam alguns passos para guiar esta composio: c.1) identificar como cada aspecto candidato afeta a propriedade que atravessa; c.2) identificar os match point, baseados na linhaOnde da Tabela 2.4 e 2.5; c.3) Identificar conflitos entre os aspectos candidatos baseados na linha Contribuio 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 composio, 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 sobrepe 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.
34
<<overlapBy>> pagar fatura <<overlapBy>>
Banco
segurana
registrar veiculo <<wrappedBy>> Proprietrio do Veculo <<wrappedBy>>
entrar na rodovia tempo de resposta <<wrappedBy>>
<<wrappedBy>> sair da rodovia Motorista
cruzar pedagio
FIGURA 2.6 EXEMPLO DE CASO DE USO COM ASPECTO CANDIDATO PASSO (C .1) . ADAPTADO DO (BRITO & MOREIRA, 2003).
Um exemplo de composio em diagrama de caso de uso, usando esses operadores de composio num sistema de cobrana de pedgio mostrado na Figura 3.6. Nesse exemplo, de Brito & Moreira (2004), o aspecto de segurana afeta os casos de uso Pagar fatura e Registrar veculo com o operador overlap; e o aspecto de tempo de resposta afeta os casos de uso Registrar veculo, Entrar na rodovia, Sair da rodovia e Cruzar pedgio. Entretanto, no indicado em que pontos do fluxo dos casos de uso esses aspectos devem ser aplicados; nem to pouco especificado como as preocupaes de segurana e tempo de resposta sero operacionalizadas no sistema de cobrana de pedgio. No trabalho anterior, Brito & Moreira (2002) i ndicam que o aspecto de segurana decomposto em duas sub-propriedades: confidenciabilidade e integridade, podendo demonstrar isso atravs de um diagrama de composio de sub-propriedades, conforme a Figura 2.7.
35
Banco
Proprietrio do Veculo
pagar fatura
registrar veiculo
<<after>> <<before>>
Confidenciabilidade
AND
Integridade
Segurana
FIGURA 2.7 USE CASE DE OVERLAP DO ASPECTO SEGURANA. ADAPTADO DO (BRITO & MOREIRA, 2002).
Para o Passo (c.2) A identificao de match points feita utilizando uma tabela entre atores e casos de uso (Tabela 2.6). Para cada interseco da clula listamos os aspectos candidatos que podem ser afetados tanto pelos atores quanto pelos casos de uso. Esta tabela servir para identificar os aspectos conflitantes.

TABELA 2.6 IDENTIFICAO DE MATCH POINTS. ADAPTADO DO (BRITO & MOREIRA, 2003). Casos de Uso Atores Registrar veculo Banco Tempo de resposta, segurana, corretude. Compatibilidade, segurana. Pagar fatura Entrar rodovia Sair rodovia
36
Cruzar pedgio
(B)
(A)
Proprietrio do veculo Tempo de resposta, segurana, corretude. Regras legais, segurana.
(D)
(C)
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 intersees das clulas em A, B, C, D, E, F e G. Em (A), por exemplo, temos trs aspectos candidatos, Para simplificar vamos considerar apenas os dois primeiros. Para verificarmos se existe um conflito que deve ser considerado, temos que olhar a especificao dos dois aspectos, Tabela 2.4 ou Tabela 2.5 na linha Contribuio, e verificar se eles contribuem negativamente para o outro, esta atividade seria o Passo (c.3). Para tentar resolver uma provvel situao entre aspectos conflitantes necessrio 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, poderamos classific-los como muito importante, logo teramos 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 Segurana. No Passo (c.5) vamos definir as regras de composio usando a informao obtida at agora.
37
Assim, a regra de composio da clula (A) poderia ficar definida como se segue: Segurana.confidenciabilidade overlaps.before RegistrarVeiculo; TempoResposta wraps RegistrarVeiculo; Segurana.integridade overlaps.after RegistrarVeiculo
FIGURA 2.8 EXEMPLO DE R EGRA DE COMPOSIO. FONTE: (BRITO & MOREIRA, 2003).
A regra de composio da Figura 2.8 expressa a ordem seqencial 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 segurana.confidenciabilidade) deve ser satisfeita antes do caso de uso Registrar Veculo. Os match points identificados na Tabela 2.6 devem ser resolvidos de forma similar.
2 .2 .3 A bo rda g e m Go a ls
A abordagem GOALS ou metas utiliza alguns conceitos relacionados diagramao do modelo i* (LIU et al, YU & MYLOPOULOS apud YU et al, 2004). O principal propsito desta abordagem a identificao de aspectos atravs do relacionamento entre metas funcionais e no- funcionais. Yu et al (2004) apresentam um trabalho fundamentado na anlise do modelo de metas (Giornini apud AORE, 2005). O modelo grfico utilizado chamado de V-Graph (Figura 2.9).
2.Desenvolvimento de Software Orientado a Aspectos Hard goals (objetivos ou metas) softgoals
38
Contribuies e correlaes
Tarefas
FIGURA 2.9 O GRFICO V-GRAPH E SUA COMPOSIO . FONTE: TRADUZIDO DE (AORE, 2005).
O V-Graph apresentado na Figura 2.9 apresenta no topo dois vrtices, hard goals e soft goals, que respectivamente so os requisitos funcionais e no funcionais em termos de modelo de metas. A representao baseada no modelo proposto por (MYLOPOULOS et al, 1992). Objetivo/ Meta Correlao SofGoal
Contribuio
Contribuio
Tarefa
FIGURA 2.10 O GRFICO V-GRAPH E SUA REPRESENTAO. FONTE: TRADUZIDO DE (YU ET AL, 2004).
Na Figura 2.10 vemos a representao grfica de Objetivo/Meta (goals o u requisitos funcionais), SoftGoal (requisitos no funcionais) e Tarefas (task). Existe uma relao de contribuio entre as Task e os Goal e SoftGoal, ou seja, uma tarefa contribui (de alguma forma) para que os requisitos funcionais ou no funcionais sejam satisfeitos. De forma similar existe uma correlao entre Goal e SofGoal.

TABELA 2.7 CONTRIBUIO E CORRELAO. ADAPTADO DO (YU ET AL, 2004).
39
Tipo de Link
ou faz Y Y
ajuda prejudica Quebra Y Y Y Y Y Y
Contribuio Y Y correlao N N
A Tabela 2.7 demonstra os tipos de relao que podem existir entre os elementos do V-Graph, onde podemos observar os tipos de link e as relaes que podem existir entre Task , Goal e SoftGoal. O processo de construo e descoberta de aspectos consiste principalmente no refinamento sistemtico do V-Graph. O processo termina quando todos os objetivos (goals) principais e todos os softgoals so satisfeitos. Nesta etapa estamos aptos a identificar aspectos candidatos atravs das tarefas que possuem um alto fan- in7 .
Lista de objetivos
decomposto Objetivo principal softgoals correlacionado
Objetivos
softgoals
Resolver conflitos
Objetivos
softgoals
tarefas
No Sim
Sem conflitos
Correlao decomposio
tarefas
No Sim No
V-Graph
Objetivos softgoals
Consistente
Sim
Satisfeito Lista de aspectos
tarefas
Aspectos
FIGURA 2.11 A VISO GERAL DA ABORDAGEM GOAL. FONTE: TRADUZIDO DE (YU ET AL, 2004).
Fan-in nmero de mdulos que chamam (ou usam); Fan-out nmero de mdulos que so chamados (ou usados) . Fonte: Constantine e Yourdon (1979)
40
A Figura 2.11 mostra uma viso do processo de modelagem do V-Graph. Inicialmente um conjunto de objetivos, incluindo um ou mais objetivos funcionais e alguns no funcionais, so listados. Depois o engenheiro de requisitos e o especialista de domnio decompe 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 operacionalizaes8 de um no funcional. O refinamento do processo pode ser sem deterioraes e os conflitos podem ser resolvidos atravs de uma anlise 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 padres ISO/IEC 9126 como ponto de partida para estabelecer metas e requisitos; e as recomendaes IEEE 830-1998 (IEEE, 1998) para a definio de especificao de requisitos. O principal argumento utilizado por MARTINEZ et al que a utilizao dos padres de qualidade ISO/IEC 9126 facilitam a identificao dos requisitos no funcionais e, por conseqncia, a identificao 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 critrios ou caractersticas desejveis referentes ao software e sua estrutura. Esta norma foi definida para os documentos tcnicos durante o ltimo encontro Internacional do SC7, em junho/1994 e possui 3 ramificaes: ISO/IEC 9126-1 -
Caractersticas e sub-caractersticas de qualidade, ISO/IEC 9126-2 - Mtricas externas , ISO/IEC 9126-3 - Mtricas internas. A Tabela 2.8 apresenta as caractersticas de qualidade ISO/IEC 9126.
Operacionalizaes se referem a um conjunto de tarefas (tasks) (AORE, 2005).

TABELA 2.8 CARACTERSTICAS DE QUALIDADE ISO/IEC 9126. ADAPTADO DO (MARTINEZ ET AL, 2004).
41
Tipo de qualidade
Caracterstica
Sub-caracterstica Adequao; Acurcia; Interoperabilidade; Conformidade; Segurana de acesso. Maturidade; Tolerncia a falhas Recuperabilidade Flexibilidade
funcionalidade
Confiabilidade
Qualidade do produto de software
Qualidade em Uso
Inteligibilidade; Apreensibilidade Usabilidade Operacionabilidade Atratividade Flexibilidade Comportamento em relao ao tempo Comportamento em relao aos Eficincia recursos flexibilidade Analisabilidade Modificabilidade Manutenibilidade Estabilidade Testabilidade Flexibilidade Adaptabilidade Portabilidade Capacidade para ser instalado Conformidade Capacidade para substituir Flexibilidade Efetividade Produtividade Segurana Satisfao
A abordagem de (MARTINEZ et al, 2004) til ao se definir um ponto de partida para os requisitos no funcionais, porm, no considera o trabalho elaborado por Yu et al (2004), que tambm explora a Abordagem Goals. Alm disso, argumenta que as outras propostas existentes (RASHID et al, 2002) (BRITO et al, 2004) no oferecem ao analista um framework o qual possa auxiliar a identificao de propriedades do sistema,
42
alm de fazerem uma distino entre requisitos funcionais e no- funcionais atravs do emprego de diferentes tcnicas para descrever os tipos de requisitos. Neste trabalho, a autora acredita ser necessria uma diferenciao dos tipos de requisitos, uma vez que so tratados de forma diferente, assim como no trabalho de Martinez (2004). Porm sem esquecermos que aspectos podem ser requisitos funcionais. Este um ponto que a abordagem de Goals no possui uma definio mais clara, pois apresenta aspectos como sendo os requisitos no-funcionais, argumentando que em sua maioria o so.
2 .2 .4 A bo rda g e m Co m Ca so s de U so
A abordagem dirigida a casos de uso prov um mtodo para desenvolver aplicaes atravs da concentrao na realizao das propriedades dos stakeholders. Jacobson & NG (2005) argumenta que os casos de uso so transversais por natureza, uma vez que sua realizao pode afetar outras classes. A principal dificuldade estava em manter as propriedades transversais separadas durante todo o processo, porm isso foi conseguido atravs do conceito de casos de uso slices (que veremos mais a seguir). Seu mtodo consiste em realizar a atualizao do modelo continuamente durante o processo.
Especificando casos de uso atualizaes
Analisando casos de uso atualizaes
Design e Implementando casos de uso atualizaes
Modelo de casos de uso
Modelo de anlise
Modelo de design
Modelo de implementao
FIGURA 2.12 ATUALIZAO DOS MODELOS NO DESENVOLVIMENTO . ADAPTADO DE (JACOBSON & NG, 2005).
A abordagem identifica dois tipos de propriedades transversais: peers e extensions. Os do tipo peers no precisam um do outro para sua existncia, podendo ser
43
desenvolvidos sistemas em separado para cada um deles, como por exemplo, transferncia de fundos, reserva de quarto e check- in. Porm, quando comeamos a implementar os peers no mesmo sistema, encontramos sobreposies significantes entre eles.
Propriedades
Componentes
Reserva de Quarto Check in Clientes Check out Clientes
Reserva quarto Tela do cliente reserva
Check in
Tela staff
quarto
Check out
FIGURA 2.13 EFEITOS DE DISPERSO E ENROLAO QUANDO REALIZAMOS PEERS. ADAPTADO DE (JACOBSON & NG, 2005).
A limitao em manter os do tipo peers separados causam dois efeitos conhecidos na linguagem aspectos como enrolao9 e disperso10 . Na enrolao podemos encontrar um componente que contem a implementao para satisfazer outros componentes, ou seja, um caso de uso tipo peers possui na sua realizao uma alterao ou implementao de um comportamento de uma outra classe (s). Na Figura 2.13 observamos que o componente Quarto est envolvido na realizao de duas diferentes propriedades. Na disperso podemos encontrar cdigos que realizam uma propriedade em particular que est espalhado atravs de mltiplos componentes. Na Figura 2.13 observamos que a realizao de Check in Clientes impe comportamento adicional em trs outros componentes. Um outro tipo de propriedade transversal chamado de extensions. O s extensions so componentes que definimos no topo da base, representam servios ou caractersticas adicionais. Embora seja natural descrever a base (ou o caso de uso base) separada da extenso, existe um problema quando implementamos a extenso.
10
Traduo literal de tangling . Traduo literal de scattering.
2.Desenvolvimento de Software Orientado a Aspectos Base Extension
44
Reserva de Quarto
Lista de Espera
Fragmento de cdigo adicionado para chamar o componente de lista de espera FIGURA 2.14 EXEMPLO DE EXTENSO . ADAPTADO DE (JACOBSON & NG, 2005).
Na figura 2.14 observamos que a extension inserida de forma intrusiva (como conhecida na linguagem aspectos) no cdigo base. Este fragmento de cdigo que chama a extension conhecido como pontos de extenso11 . Nesta abordagem so utilizados alguns conceitos da linguagem AspectJ, como pointcuts, que identificam um ponto de execuo no cdigo 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 separao de propriedades atravs do design e implementao, para evitar os problemas de disperso e enrolao j citados. Assim, necessrio colecionar a especificao dos casos de uso durante o design em uma unidade modular, denominada use case slice 12 . Cada use case slice possui partes de classes, operaes, 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, operaes e relacionamentos destas classes. Algumas destas classes e suas caractersticas so especficas da realizao do caso de uso, outras so necessrias, porm so de outros casos de uso. Cada use case slice contm a especificao da realizao do caso de uso em um modelo. A parte genrica e reusvel so mantidas em casos de uso especficos no slices. Todos estes slices so ento agrupados para formar todo o modelo de design.
11 12
Traduo literal de extension points. A traduo para o termo utilizado ficaria: pedaos de casos de uso. Porm iremos utilizar o termo em ingls.

Estrutura de elementos Estrutura casos de uso
45
Camada aplicao composio
Camada domnio
composio
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 contedo (comportamento) ser preenchido atravs dos casos de uso slices atravs do mecanismo de composio. Ou seja, os casos de uso slice no contm a classe completa, possui apenas parte delas, chamadas de extenso da classe. As extenses da classe contm apenas as caractersticas necessrias para concretizar o caso de uso.
Casos de Uso Comportamento da extenso da classe especfico da realizao do caso de uso Reserva Quarto
Reserva Quarto Check in slices Check in Check out
Check out Reserva Quarto +Check in + Check out Classes Tela cliente Tela Staff Reserva Check Check Quarto in out Reserva Quarto
FIGURA 2.16 COMPOSIO DA REALIZAO DE CASOS DE USO PEER COM CASOS DE USO SLICES. ADAPTADO DE (JACOBSON & NG, 2005).
46
A figura 2.16 demonstra um exemplo dos casos de uso base e seus slices, com as partes das classes e onde elas so atualizadas. Jacobson & Ng (2005) tambm argumentam que a representao tradicional de casos de uso pode no ser clara o suficiente quando queremos especificar as sub-rotinas ou extenses existentes no fluxo.
Reserva de Quarto Reserva de Quarto Flows {basic} Reserva quarto {alt}submisso duplicada {sub}checar custo do quarto
(A)
(B)
FIGURA 2.17 REPRESENTAO DE CASOS DE USO . ADAPTADO DE (JACOBSON & NG, 2005).
Embora a representao (B) da Figura 2.17 seja mais clara, pois especifica os fluxos existentes, no possui ferramenta case para constru- la. A representao dos requisitos no- funcionais realizada atravs de um caso de uso especial chamado de perform transaction e os requisitos funcionais (os tradicionais e usuais) chamamos de casos de uso de aplicao.
tratar autorizao <<extend>>
<<extend>> realizar auditoria transaes <perform transaction>
<ator>
<<extend>>
rastrear preferncias
FIGURA 2.18 ESTRUTURANDO CASOS DE USO DE INFRA-ESTRUTURA. ADAPTADO DE (JACOBSON & NG, 2005).
A Figura 2.18 demonstra a utilizao de um exemplo de casos de uso de infraestrutura (no funcionais). Apesar dos requisitos no- funcionais serem tratados como extends, eles fazem parte de um caso de uso nico, o < perform transaction> que requisitado para executar os requisitos no- funcionais.
47
Ao lidar com um requisito de tempo de resposta de 2 segundos, por exemplo, devemos modelar e expressar este tipo de requisito como declaraes na seo especial do use case <perform transaction>, como demonstra a Figura 2.19.
Especificao de Caso de Uso: <perform transaction> Fluxo Bsico O caso de uso comea quando um ator instancia a execuo de uma transao para visualizar valores de uma instncia de uma entidade. 1. O sistema indica a instncia do ator que identifica a instncia da entidade desejada. 2. A instncia do ator entra com valores e submete sua requisio. 3. O sistema resgata a instncia 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 bsico a requisio requer autorizao, o sistema checa os direitos da instancia do ator. 1. Se a instancia do ator no possui direitos de acesso a requisio rejeitada. O caso de uso termina. 2. Caso contrario, o caso de uso continua. A2. Preferncia do Usurio No passo 1 do fluxo bsico, se a prioridade principal definida, o sistema carrega a preferncia e usa aqueles valores como padro para a requisio da instancia do ator. O caso de uso reinicia. No passo 2 do fluxo bsico, se o usurio indica que o valor submetido ser usado como padro, o sistema armazena como uma preferncia do usurio. A3. Logging No passo 2 do fluxo bsico, a requisio deve ser logada; o sistema armazena a requisio solicitada no arquivo de log. Requisitos especiais Todos as chamadas no devem demorar mais do que 2 segundos.
FIGURA 2.19 A ESPECIFICAO DO CASO DE USO <PERFORM TRANSACTION>. ADAPTADO DE (JACOBSON & NG, 2005).
Souza (2004) argumentou em seu trabalho que nesta abordagem no se podia manter a separao de propriedades durante o ciclo de vida do processo, sendo ineficiente. Porm, seu trabalho no incluiu o trabalho atual do Jacobson & Ng (2004), pois sua publicao foi posterior a dissertao de Souza. Assim, com o ultimo trabalho de Jacobson
48
& 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 definio do trabalho de Souza (2004) com os casos de uso, utilizada uma tabela de composio para identificar o tipo de composio do aspecto em relao ao caso de uso afetado, bem como uma tabela de resoluo de conflitos para o caso em que dois aspectos diferentes devem ser includos no mesmo ponto de juno do caso de uso afetado. Jacobson & Ng (2004) acreditam que o desenvolvimento de software se resume a construir modelos. Comeamos com o modelo de casos de uso para capturar as propriedades d o s stakeholders, refinamos este modelo no modelo de anlise, o qual tambm formula uma viso de alto nvel do sistema, preparamos a estratgia de como o sistema executar na plataforma com o modelo de design, e no modelo de implementao, temos os cdigos atuais e binrios. Isto previsto por qualquer processo de desenvolvimento existente, porm na abordagem com casos de uso isto feito caso de uso por caso de uso atravs do refinamento e realizao. 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 mdulo de caso de uso. Este mdulo compreende os use-case slices de cada modelo. Os mdulos de casos de uso so desenvolvidos separadamente e depois compostos para formar o sistema como um todo.
2 .2 .5 A bo rda g e m The me /DOC

A Abordagem Theme constituda 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 coleo de estruturas e comportamentos que representam uma caracterstica.
13
Traduo literal de package
49
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. ANLISE
Requisitos escolher Themes
rede
viso Relacionamentos mostrar Base Aspectos retrabalho
retrabalho DESIGN Base
modelos
Aspectos
Aspectos (surgidos do
baixo nvel design)
escrever COMPOSIO Especificao da composio verificar viso Design da composio retrabalho
automtico Theme/UML
Theme/Doc
FIGURA 2.20 . O PROCESSO THEME. ADAPTADO DE (CLARKE & BANIASSAD, 2005).
50
Na Figura 2.20 podemos observar que a representao Theme/Doc usada para visualizar e analisar requisitos e Theme/UML usada na aplicao de projeto. De maneira geral o processo Theme dividido em trs atividades principais: a) Anlise onde realizado a anlise dos requisitos para identificao dos themes. Esta atividade envolve o mapeamento dos requisitos para propriedades no sistema. Theme/Doc permite a visualizao dos
relacionamentos entre os comportamentos. Estes relacionamentos expem as propriedades enrolados14 e permite a identificao dos aspectos. b) Design O design dos themes feito utilizando o Theme/UML. No Theme/Doc identificamos classes e mtodos em potencial, depois preenchemos os detalhes de design e realizamos mudanas que so necessrias para o benefcio do design. Outros aspectos aparecem durante o detalhamento tcnico do design. c) Composio Nesta fase especificamos como os modelos Theme/UML devem ser combinados. Em muitos casos, algumas vises do Theme/Doc auxiliam na determinao de como os themes se relacionam com outro: se eles se sobrepem ou se eles atravessam15 o outro. Na Figura 2.20 observamos que temos algumas setas com a indicao de automtico, isto devido a ferramenta citada por Baniassad & Clarke (2004b), porm, no est disponvel para download (THEME, 2006). Veremos com mais ateno a abordagem Theme/Doc, por se tratar da anlise de requisitos. Baniassad & Clarke (2004b) definem que aspectos so comportamentos que esto espalhados pelo sistema e, no documento de requisitos, eles se manifestam como descries de comportamentos que esto interconectados e entrelaados por todo o tempo. Um ponto interessante nesta abordagem que no se pode identificar aspectos em requisitos com termos de ao nicos, ou seja, as aes (ou verbos de ao na sentena) so considerados como themes. Assim, se todos os requisitos so nicos (se referem a um nico verbo de ao) no possuem aspectos. Neste caso necessrio, muitas vezes, refazer os requisitos.
14 15
Traduo literal de tangled Traduo literal de crosscut
51
Um outro ponto a considerar so os requisitos no funcionais. Nestes casos no h palavras de ao, porm, eles so transversais por natureza e a soluo, nestes casos, igualmente refazer os requisitos para incluir tais caractersticas. 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 sobrepe a funcionalidades dos base themes. O processo theme/Doc possui as seguintes atividades a serem desenvolvidas: 1) Identificar themes em potencial a identificao feita a partir de aes chaves no documento de requisitos. Na realidade feita uma anlise do documento de requisitos e identificados entidades chaves e propriedades chaves. Em um prximo passo, feito uma iterao sobre o conjunto para decidir se: acrescenta, deleta, divide ou agrupa os themes. Clarke & Baniassad (2005) argumenta que podemos comear com a escolha de nomes de caractersticas, servios, ou casos de uso do sistema para chegar no ponto inicial de themes. Baniassad & Clarke (2004b) indica a escolha dos verbos de ao 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 caractersticas sero themes, porm esta tarefa de escolha das entidades e palavras de ao ainda manual na ferramenta (THEME, 2006) e depende da experincia do engenheiro de requisitos. importante observar que palavras sinnimas que se referem a mesma ao devem ser agrupadas sobre uma nica palavra de ao. Com esta atividade realizada a ferramenta gera o grfico de Viso de Aes Figura 2.21. Onde a elipse um theme e um retngulo se refere ao requisito.
52
Primeiro Theme Segundo Theme
Requisito 1: se refere ao primeiro e segundo theme Requisito 2: se refere ao terceiro theme
Terceiro Theme
FIGURA 2.21 . EXEMPLO ABSTRATO DO GRFICO DE VISO DE AES16 . 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 ao, est caracterizado um comportamento enrolado17 ou complicado. Este relacionamento deve ser analisado para verificar se uma m especificao de requisitos ou se existe um comportamento crosscutting. No caso de muitas ligaes entre os requisitos a palavras de ao, onde a verificao foi feita e foi decidido que do jeito que est especificado, a ao predominante para o requisito deve ser definida (e assim selecionada como base), e a segunda ao deve ser ligada a primeira, indicando que a segunda ao /comportamento atravessa o comportamento base. Aps todos os requisitos compartilhados serem ligados ao seu comportamento secundrio o grfico de Viso de Aes Ligadas obtido, conforme a Figura 2.22. Nesta figura a linha pontilhada indica que no houve deciso 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 grfico a linha cinza indica o relacionamento de crosscutting.
16 BANIASSAD&CLARKE ( 2004b). chamam este grfico de Action Views e em C L A R K E & BANIASSAD ( 2005) este mesmo grfico chamado de Relationship view, porm so idnticos nos conceitos. 17 Traduo literal de tangling
53
Terceiro Theme
Requisito 3: se refere ao terceiro theme

Primeiro Theme
Requisito 1: se refere ao primeiro e segundo theme

Segundo Theme
FIGURA 2.22 . EXEMPLO ABSTRATO DO GRFICO DE AES LIGADAS18. ADAPTADO DE (CLARKE & BANIASSAD, 2005).
3) Preparar para design O grfico theme view usado para planejar o design e a modelagem dos themes identificados no passo anterior. Este grfico difere do grfico de viso de aes no sentido de que no apenas mostrar os requisitos e as aes, mas tambm mostrar os elementos do sistema necessrios a serem considerados para cada theme design no Theme/UML. Para construir esta viso o desenvolvedor/engenheiro de requisitos deve fornecer um conjunto adicional de informaes, as entidades chave. A figura 2.23 mostra um exemplo deste grfico. Usamos o theme view para planejar as classes e mtodos no Theme/UML. Ao modelarmos usamos as prticas de design de orientao a objetos para auxiliar na determinao de quais classes e mtodos so descritos. Na maior parte dos casos os mtodos so as aes e as classes so as entidades, porm podemos acrescentar outras entidades e mtodos como decises de design. Assim, torna-se claro que apesar de enderear quase todos os requisitos ainda no suficiente se este endereamento ir suprir todas as necessidades (de classes e entidades), uma vez que pode ser acrescido de elementos no identificados inicialmente.
18
BANIASSAD&CLARKE (2004b). chama este grfico de Clipped Views e em CLARKE & BANIASSAD (2005) chama este grfico de Crosscutting view, porm os conceitos so os mesmos.
54

Segundo Theme Primeiro Theme
Primeiro elemento Segundo elemento
Terceiro Theme
Requisito 3: se refere ao primeiro theme e ao terceiro theme
FIGURA 2.23 . EXEMPLO ABSTRATO DO GRFICO DE THEME VIEW. ADAPTADO DE (CLARKE & BANIASSAD, 2005).
2 .3 Co m pa ra o e nt re A bo rda g e ns Apre se nta da s

Todas as abordagens possuem um ponto em comum quando afirmam que com a identificao de propriedades transversais nas fases iniciais do processo de
desenvolvimento pode-se obter benefcios da sua utilizao nos artefatos de requisitos, anlise e projeto, e no apenas na implementao, como era feito logo no incio da orientao a aspectos. Partindo desta premissa e baseado nas caractersticas de qualidade elaboradas pela ISO/IEC 9126, definimos algumas caractersticas a serem consideradas para a comparao entre as abordagens, que definimos de acordo com a Tabela 2.9 e 2.10 A Tabela 2.9 apresenta as caractersticas gerais e seus conceitos, de acordo com a norma ISO/IEC 9126 e adaptadas para o nosso propsito, e a Tabela 2.10 apresenta as sub-caractersticas que serviro de base comparao efetuada, apresentada na Tabela 2.12.
55
Vale observar que as sub-caractersticas listadas na Tabela 2.10 correspondem a uma adaptao das sub-caractersticas originais, apresentadas nas normas ISO/IEC 9126. As sub-caractersticas em fundo amarelo foram includas para realizar a comparao e no existia originalmente. As outras foram adaptadas em seus conceitos para realizar tal comparao
TABELA 2.9 ADAPTAO DOS CONCEITOS DAS CARACTERSTICAS DE QUALIDADE ISO/IEC 9126
Caractersticas de Qualidade
Funcionalidade Evidencia que o conjunto de funes atende s necessidades explcitas e implcitas para a finalidade a que se destina a abordagem. Confiabilidade Evidencia que o desempenho se mantm ao longo do ciclo ou fase a que se destina e em condies estabelecidas. Usabilidade Eficincia Evidencia a facilidade para a utilizao da abordagem. Evidencia que os recursos e os tempos envolvidos para a aplicao da abordagem so compatveis com o nvel de desempenho requerido para a aplicao da abordagem. Manutenibilidade Evidencia que h facilidades para correes, atualizaes e alteraes durante a sua aplicao. Portabilidade Evidencia que possvel utilizar a abordagem em diversas plataformas (utilizando sua ferramenta Case) com pequeno esforo de adaptao.
56
TABELA 2.10 S UB-CARACTERSTICAS PARA COMPARAO DAS ABORDAGENS
Caracteristica
Sub-caracteristica Abrangncia Adequao
Funcionalidade Acurcia Interoperabilidade Conformidade Confiabilidade Origem Maturidade Artefatos Usabilidade Apoio Case Inteligibilidade Apreensibilidade Resoluo de Conflitos Tratamento de Requisitos Organizacionais Requisitos funcionais aspectos Requisitos no funcionais aspectos Comportamento em relao aos recursos Rastreabilidade Manutenibilidade Analisabilidade Modificabilidade Testabilidade Adaptabilidade Portabilidade Capacidade para ser instalada Capacidade para substituir
Conceito Indica qual a fase do processo de desenvolvimento considerada na abordagem A abordagem deve ter um conjunto de funes/passos apropriados para a separao e composio de propriedade Gerao de resultados satisfatrios. (indicar ponto fraco) Capacidade de interagir com outros produtos Estar de acordo com normas, convenes e regulamentaes. Ano do primeiro trabalho publicado da proposta Grau de maturidade da proposta Principal artefato utilizado para a elucidao dos aspectos e propriedades Indica se a abordagem possui ferramenta Case de Apoio Facilidade oferecida ao usurio em entender os conceitos utilizados Facilidade de aprendizado Indica se a abordagem possui mecanismos ( e seu nvel) bem definidos para a resoluo de conflitos Indica se a abordagem possui estratgia de tratamento para requisitos organizacionais. Indica se a abordagem considera que requisitos funcionais possam ser aspectos Indica se a abordagem considera que requisitos no funcionais possam ser aspectos; Quantidade de recursos (artefatos) utilizados para a execuo das tarefas Indica se a abordagem oferece um mtodo para realizar o rastreamento de aspectos durante o ciclo de vida de desenvolvimento Facilidade de diagnosticar deficincias e causas de falhas Facilidade de modificao e remoo de defeitos Facilidade da abordagem ser testada e validada Capacidade de ser adaptada a ambientes diferentes Facilidade para executar a instalao em ambientes especficos (ao possuir ferramenta que a implemente) Facilidade em substituir outra abordagem utilizada pelos desenvolvedores
Eficincia
57
Para os critrios utilizados para a comparao efetuada entre as abordagens adotou-se trs nveis de avaliao: fraca, regular e boa. A especificao de cada uma encontra-se na Tabela 2.11. Este critrio foi utilizado na comparao efetuada na tabela 2.12.
TABELA 2.11 CRITRIOS DE PADRES UTILIZADOS NA COMPARAO Caracterstica Abrangncia Boa Abrange a todas as fases do desenvolvimento de software Conjunto de artefatos e fases bem definidas Critrios Regular Abrange mais que uma fase do desenvolvimento de software. Um ou mais artefatos com pouca ou nenhuma definio ou uma ou mais fases com pouca ou nenhuma definio Deixa de gerar um artefato de forma satisfatria ou com pouca objetividade Possui exportao para alguns formatos, porm dentro da prpria famlia do fabricante. Fraca Abrange apenas uma fase do desenvolvimento de software. Um ou mais artefatos com pouca ou nenhuma definio e uma ou mais fases com pouca ou nenhuma definio Deixa de gerar mais de um artefato de forma satisfatria ou com pouca objetividade No possui
Adequao
Acurcia
Gera todos os artefatos de forma satisfatria e com objetividade
Feita atravs de uma especificao para a exportao em formato padro (XML, MOF, etc.) Conformidade Segue padres Segue padro da prpria No possui padro conhecidos (UML, etc) famlia do fabricante. Origem* No possui critrio. Apenas indica o ano da primeira publicao da abordagem. Possui vrias Possui publicaes (at Possui at duas Maturidade publicaes (mais de 3) trs) , porm no h publicaes. e/ou livro da abordagem livro sobre o assunto. Possui mais de trs Possui at trs artefatos. Possui um artefato artefatos (grficos, principal. Artefatos tabelas, etc) para apoiar a abordagem Possui ferramenta case Possui ferramenta, mas No possui ferramenta disponvel para apoiar o no se encontra case. Apoio Case desenvolvimento disponvel para download Artefatos simples e bem Possui artefatos simples Artefatos complexos e Inteligibilidade definidos e alguns complexos difceis de entender Objetiva e fcil de Conceitos mais Conceitos complexos e entender os conceitos complexos, porm no com grau de dificuldade Apreensabilidade apresenta dificuldade mdio para alto alta. Apresenta mecanismos Apresenta mecanismos No apresenta Resoluo de Conflitos simples e bem definidos complexos para mecanismos resoluo de conflitos Tratamento de Possui tratamento de Possui tratamento de No possui Requisitos forma diferenciada forma unificada com organizacionais RNF Considera e possui Considera, mas no pos- No considera Requisitos funcionais tratamento especfico sui tratamento diferenciaspectos ado ou no explica como Continua na prxima pgina Interoperabilidade

Continuao da Tabela 2.11 Caracterstica Requisitos no funcionais aspectos Boa Considera e possui tratamento especfico No possui quantidade definida (ou possui sem o rigor da obrigatoriedade), porem todos so bem objetivos e simples Possui mecanismos para rastrear aspectos de forma simples e direta Facilmente detectvel, mesmo que de forma manual Facilmente modificvel (com ajuda de ferramenta case) Facilmente testvel Independente de ambiente Linguagem independente de plataforma Sem problema, apenas incorporar novos conceitos
58
Comportamento em relao aos recursos
Critrios Regular Considera, mas no possui tratamento diferenciado ou no explica como Possui quantidade definida e todos so necessrios
Fraca No considera
Possui quantidade bem definida, porm alguns no so bem objetivos
Rastreabilidade
Analisabilidade
Possui mecanismos, porm sem rastreabilidade durante a fase inicial detectvel, porem com o uso de ferramenta prpria Modificao complexa
No possui
No possui ou possui de forma complexa e pouco usual No possui
Modificabilidade Testabilidade Adaptabilidade Capacidade para ser instalada
Dificuldade maior (depende de aprovao) Com adaptaes Diferentes verses para plataformas distintas Alguns conceitos complexos com a mudana porm utilizando a mesma base da abordagem
No possui No possui No disponvel
Capacidade para substituio
Mudanas complexas e totais no desenvolvimento
A Tabela 2.12 apresenta a comparao entre as abordagens estudadas neste captulo. Alguns estudos comparativos entre as abordagens utilizam outros critrios de avaliao, como o tipo de regra de composio utilizada, por exemplo. Porm utilizamos os critrios de qualidade das normas ISO/IEC 9126 por ter maior abrangncia, de forma a evidenciar as diferenas e dificuldades entre cada abordagem.

TABELA 2.12 COMPARAO DAS ABORDAGENS AORE FATORES Abrangncia Adequao Acurcia Viewpoint fraca fraca fraca. identificao dos propriedadess regular. regular Abordagem Goals fraca fraca fraca. refinao de objetivos Use Case boa regular regular
59
Funcionalidade
Theme /Doc boa regular regular
Interoperabilidade Conformidade
fraca Boa (i* com adaptaes) 2004 regular Boa (V-GRAPH refinados) Boa(OPENOME)
Confiabi -
lidade
Origem Maturidade Artefatos
2002 regular Boa (XML) Regular (ARCADE) regular regular boa fraca fraca Boa regular boa boa
fraca Boa (UML com adaptaes) 2003 boa Boa (Casos de Uso) fraca
fraca regular
2004 boa Boa (Grfico Theme-Doc ) Fraca (Theme/DOC Tool) regular regular regular fraca Boa Boa regular boa Regular (no disponvel) Boa (com restries) regular fraca fraca fraca
Usabilidade
Apoio Case Inteligibilidade Apreensabilidade Resoluo de Conflitos Tratamento de Requisitos organizacionais Requisitos funcionais aspectos Requisitos no funcionais aspectos Comportamento em relao aos recursos Rastreabilidade
Boa regular boa fraca fraca Boa Boa boa boa
regular regular regular fraca regular Boa Boa boa Regular (sem ferramenta) regular fraca regular fraca regular
Manutenibilidade
Eficincia
Analisabilidade Modificabilidade Testabilidade Adaptabilidade Boa (com restries) regular boa Boa (com restries) Boa (se anterior for Viewpoint, seno ser regular) Boa boa Regular Boa Boa (se anterior for Goals seno ser regular)
Portabilidade
Capacidade para ser instalada
Capacidade para substituio
60
As tabelas 2.13, 2.14, 2.15 e 2.16 apresentam um resumo das caractersticas de qualidade, apresentando os principais problemas encontrados. Este resumo foi baseado nas respostas apresentadas e proporciona uma viso geral da Tabela 2.12.
TABELA 2.13 RESUMO DA COMPARAO ABORDAGEM VIEWPOINT
Abordagem Fraca Funcionalidade:
Viewpoint
Sua principal dificuldade est na identificao das propriedades, onde esta atividade no est definida objetivamente. Deixando a cargo da experincia do engenheiro de requisitos. Fraca Apesar de ter sua origem na orientao a objetos, esta abordagem ainda no possui a maturidade necessria para ser considerada regular. Esta classificao deve-se ao fato de estar particularmente focada em uma universidade e no ter vasto material de pesquisa disponvel. regular Apesar de possuir fases bem objetivas e definidas com seus artefatos, a primeira fase no bem definida (sendo a mais importante). Seus artefatos possuem facilidade de aprendizado e so bem simples no seu contedo, o que garantiu uma classificao regular. regular Apesar de no tratar requisitos organizacionais e no considerar requisitos funcionais como aspectos, esta abordagem possui um bom mtodo para tratamento de conflitos e tratamento para requisitos no funcionais de forma bem especfica, o que garantiu uma classificao regular boa
Confiabilidade:
Usabilidade
Eficincia
Esta classificao se deve ao fato de que esta abordagem Manutenibilidade possui um bom nvel de rastreabilidade, mesmo que manual, porm com um pouco mais de trabalho e uma boa manuteno (se estiver com a ferramenta). Boa Portabilidade A substituio para esta abordagem ser mais simples se a abordagem anterior for a OO para Viewpoint, seno ser um pouco mais complicado. Possui ferramenta para auxlio feita em Java, porem sem possibilidade de download. O que dificulta um pouco a avaliao como um todo.

TABELA 3.14 RESUMO DA COMPARAO ABORDAGEM GOALS
61
Abordagem Fraca Funcionalidade:
GOALS Sua principal dificuldade est no refinamento sucessivo dos objetivos e suas operacionalizaes, uma vez que esta atividade no est definida claramente, deixando a cargo da experincia do engenheiro de requisitos. Regular Apesar de ter sua origem na orientao a objetos com a modelagem i*, esta abordagem ainda no possui a maturidade necessria para ser considerada boa. Esta classificao deve-se ao fato de estar sendo utilizada por algumas faculdades (inclusive em cursos de especializao UNIOESTE no Paran) e ter vasto material de pesquisa disponvel. Boa O mtodo em si bem simples, pois baseia-se no refinamento sucessivo de objetivos, o que garante a classificao atual. regular Conceitualmente a modelagem i* pode tratar requisitos organizacionais (em trabalhos adicionais como em SANTANDER (2002)), porm no especifica este assunto, tratando apenas das operacionalizaes dos requisitos no funcionais. Boa
Confiabilidade:
Usabilidade
Eficincia
Manutenibilidade Possui uma boa rastreabilidade (atravs do refinamento sucessivo dos objetivos) e uma boa analisabilidade (atravs das tarefas que satisfazem os objetivos). Boa A substituio da viso OO (i*) para a viso de aspectos bem simples, pois os conceitos so praticamente os mesmos, caso contrario fica mais complexo o processo de substituio, porm os conceitos so simples. A ferramenta possui vrias verses diferentes e est disponvel para download.
Portabilidade
62
TABELA 2.15 RESUMO DA COMPARAO ABORDAGEM USE CASE
Abordagem Regular
USE CASE
Sua principal dificuldade est na definio dos casos de uso Funcionalidade: como um todo, iniciar o processo de desenvolvimento com a definio dos casos de uso no uma tarefa trivial. Suas fases so completas e complexas, o que garante uma classificao regular. Boa Confiabilidade: Uma das nicas abordagens conhecidas que possuem definio para todas as fases do processo de desenvolvimento. O que garante uma classificao boa. Regular Usabilidade Mesmo para quem utiliza os casos de uso, so muitos conceitos novos e complexos, o que garante a classificao atual. Regular Eficincia Conceitualmente os casos de uso tratam apenas de funcionalidades do sistema. Com esta abordagem eles passam a tratar dos requisitos no funcionais, sem abordar os requisitos organizacionais.. Regular Manutenibilidade No possuindo uma ferramenta case para auxiliar o processo, fica complexo e demanda tempo a tarefa de manuteno, analisabilidade e rastreamento. Regular Portabilidade A substituio da viso OO para a de aspectos no simples, pois abrange vrios conceitos novos e complexos, o que garantiu a classificao regular.

TABELA 2.16 RESUMO DA COMPARAO ABORDAGEM THEME/DOC
63
Abordagem Funcionalidade:
THEME/DOC Regular Sua principal dificuldade est na definio dos themes, pois uma tarefa manual, porm o processo de construo dos requisitos na abordagem bem simples, o que garante a classificao atual. Boa Uma das nicas abordagens conhecidas que possuem definio para todas as fases do processo de desenvolvimento. O que garante uma classificao boa. Regular Mesmo sendo uma abordagem completamente diferente e recente, garante esta classificao por ser bem simples. fcil de ser compreendida e de ser usada, apesar da ferramenta case no estar disponvel. a que mais se aproxima da especificao do LEL (mesmo que nem cite o mesmo) Regular Consegue tratar requisitos funcionais e no funcionais com simplicidade, apesar de ter regras rgidas para a composio dos mesmos. A identificao dos aspectos bem simples e possui tratamento para a resoluo de conflitos. Regular No possuindo uma ferramenta case disponvel para download para auxiliar o processo fica complicado a tarefa de manuteno, analisabilidade e rastreamento. Fraca A substituio para esta abordagem no simples, uma vez que completamente diferente das outras e de um padro j existente em OO. No h informao sobre a ferramenta e sua implementao, o que dificulta o processo de anlise.
Confiabilidade:
Usabilidade
Eficincia
Manutenibilidade
Portabilidade
TABELA 2.17 RESUMO GERAL DA COMPARAO
Fatores Funcionalidade Confiabilidade Usabilidade Eficincia Manutenibilidade Portabilidade
Abordagem Viewpoint Fraca Fraca regular regular boa Boa Goals Fraca. Regula Boa regular Boa Boa. Use Case Regular Boa Regular Regular Regular Regular Theme /Doc Regular. Boa Regular Regular Regular Fraca
64
A Tabela 2.17 demonstra que apesar dos esforos oriundos dos estudos das abordagens, muitos atributos so frgeis em relao ao que se propem. Assim, um estudo mais aprofundado, englobando estudos de caso em cada abordagem imprescindvel para avaliar melhor o impacto de cada uma das abordagens apresentadas, ficando de sugesto como trabalho futuro a ser apresentado.
2 .4 Re sumo do Ca pt ulo
Neste captulo foram apresentados os principais conceitos do desenvolvimento orientado a aspectos e as principais abordagens apresentadas na Engenharia de Requisitos. Ao final apresentamos uma comparao entre as abordagens com o intuito de evidenciar as diferenas (vantagens e desvantagens) entre cada uma. Esta comparao importante a partir do q u e ser a base para o desenvolvimento da nova abordagem. Neste captulo identificamos que uma das principais dificuldades apresentadas pelas abordagens est em como identificar propriedades, propriedades transversais e, por conseqncia, aspectos. De maneira geral, as abordagens definem estes conceitos, porm no 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 prximo captulo veremos alguns conceitos gerais da MDSODI, do ambiente DISEN e da ferramenta Requisite.
3.A Metodologia MDSODI e o Ambiente DiSEN
65
CAPTULO
3
A METODOGIA MDSODI E O AMBIENTE DISEN
Eu no consigo entender por que as pessoas tm medo das novas idias, eu tenho medo das velhas. John Cage
Des de meados da dc ada de 70 com a An lis e Es truturada, os des envolvedores tem s e deparado com s is temas c ada vez ma is c omplexos e d if c eis de me ns urar e e ntender de uma ma ne ir a ma is s imp les e completa, da tem s urgido tantas metodologias e abordagens difer entes para es pec ific a o de s is temas . Pres s man (2005), muito s abiame nte, j d iz ia que ns nos c erc amos de vr ias metodologias e es pec if ic a es apenas para gar ant ir que es tamos c ompreendendo o que es tamos fazendo. A verdade que com o avan o da tec nologia, a tendnc ia que tenha mos s is temas c ada vez ma is c omplexos . Portanto, o s urgime nto de novos mtodos e tc nic as de des envolvimento s o plename nte c ompreens veis , tanto no que d iz res peito nos s a compreens o quanto no que diz res peito tec nologia e s eu avan o.
66
Nes te ponto entra a Metodologia de Des envolvimento de Software ou Sis temas Dis tr ibu dos MDSODI1 (GRAVENA, 2000), que leva em c ons idera o algumas c arac ter s tic as ident if ic adas em t a is s is temas , c omo: para le lis mo/c oncorrnc ia, c omunic a o, s inc roniza o e dis tribui o, j nas fas es inic ia is do projeto. Es te c ap tulo tem por objet ivo apres enta r e des c rever a MDSODI, apres entar o Ambiente de Des envolvimento de Software Dis tr ibu do DiSEN (PASCUTTI,2002) e a ferra ment a REQUISITE (BATISTA, 2003) em s eu es tado atual.
3 .1 A Me to do lo g ia MDS OD I
A MDSODI uma metodologia para desenvolvimento de software distribudo e foi proposta por Gravena (2000). Esta metodologia considera aspectos de
concorrncia/paralelismo, comunicao, sincronizao e distribuio no seu desenvolvimento em todas as fases do desenvolvimento de software. Estes aspectos so representados atravs da extenso UML (GRAVENA, 2000) (HUZITA, 1999). O modelo do ciclo de vida da MDSODI e suas fases podem ser visto na Figura 3.1. Inc #1
Inc #1
Inc #1
...
Inc #1
GERENCIAMENTO
Requisitos
Anlise
Projeto
Implementao
Teste
FIGURA 3.1 CICLO DE VIDA DO MDSODI. FONTE: (GRAVENA, 2000)
Es ta meto d o lo g ia fo i d es en v o lv id a atrav s d e u m p ro jeto d e p es q u is a em 19 9 9 ( H UZITA , 1 9 99 ) n o Lab o rat rio d e En g en h aria d e So ft ware ( LES) d o Dep arta men to d e In fo r mtica (D I N) d a Un iv ers id ad e Es tad u al d e M arin g (U EM ).
67
Cada incremento composto das fases de requisitos, anlise, projeto, implementao e teste, conforme observado na Figura 3.1. Cada fase possui os seguintes objetivos: 1. Fase de Requisitos Identificar as funcionalidades necessrias para o desenvolvimento do sistema de uma forma adequada e eficiente a partir das necessidades do usurio. Nesta fase, devem-se entender os requisitos funcionais e no funcionais e elaborar o diagrama de casos de uso considerando os aspectos de paralelismo/concorrncia e distribuio. Os artefatos produzidos so: modelo de negcio, diagrama de use case e descrio de requisitos. 2. Fase Anlise 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 concorrncia/paralelismo, distribuio e comunicao entre as classes. Devem-se tambm identificar os aspectos de concorrncia/paralelismo e a distribuio entre pacotes atravs de descrio textual, quando necessrio, e elaborar o diagrama de pacotes considerando estes aspectos. Nesta fase so produzidos os artefatos: diagramas de classe, diagrama de colaborao, diagrama de estado, diagrama de pacotes e descrio arquitetural do modelo de anlise. 3. Fase de Projeto Nesta fase elaborado o diagrama de classes de projeto, definio de aspectos da arquitetura do sistema, identificando a alocao dos pacotes nas camadas, e detalhamento de algoritmos, todos considerando os aspectos de paralelismo e distribuio. Nesta fase so produzidos os artefatos: diagrama de seqncia (paralelismo, distribuio e comunicao), lista com os requisitos de implementao (linguagem e ambiente de programao escolhidos), localizao fsica e questes de concorrncia (entre mtodos), diagrama de subsistema (considerando sincronizao, paralelismo, distribuio e comunicao), diviso do sistema em camadas, aspectos arquiteturais do projeto, averiguao de componentes disponveis para reutilizao e detalhamento dos mtodos. 4. Fase de Implementao esta fase tem como objetivo a construo e implementao 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 mtodos das classes. Os mecanismos de sincronizao e os que tratam do balanceamento de carga entre os ns do processamento, considerando os requisitos de distribuio, paralelismo, sincronizao e comunicao devem ser tratados.
68
5.
Fase de teste constitui-se em um trabalho a ser desenvolvido (GRAVENA, 2000).
A MDSODI prope tambm uma definio de notao para a especificao de seus elementos nos artefatos (Casos de uso, atores, classes e objetos, e relacionamentos). A tabela 3.1 ilustra esta especificao adotada.
TABELA 3.1 ESPECIFICAO DOS ELEMENTOS UTILIZADOS NA MDSODI. FONTE: (GRAVENA, 2000)
Tipos de Casos de Uso Casos de Uso Casos de Uso Seqenciais: agrupam um conjunto de funcionalidades que devem ser executadas seqencialmente. Casos de Uso Paralelos: agrupam um conjunto de funcionalidades que devem ser executadas em paralelo. Casos de Uso Distribudos: podem estar em diferentes locais do sistema. Casos de Uso Paralelos e Distribudos: podem estar em diferentes locais do sistema e devem ser executados em paralelo. Tipos de Atores Atores Atores Exclusivos: atores envolvidos com casos de uso seqenciais. Atores Paralelos: atores envolvidos com casos de uso paralelos. Notao Notao
Atores Distribudos: atores que se encontram localizados em diferentes ns no sistema. Atores Paralelos e Distribudos: atores que so, ao mesmo tempo, paralelos e distribudos. Tipos de Classes/Objetos Classes/Objetos Classes e Objetos Exclusivos: Todos os seus mtodos so executados sequencialmente. Classes e Objetos Parcialmente Paralelos: alguns mtodos so executados sequencialmente enquanto outros concorrentemente. Notao
69
Classes e Objetos Totalmente Paralelos: todos os mtodos so executados concorrentemente. Classes e Objetos Distribudos: os mtodos podem ser executados em diferentes ns do sistema. Tipos de Relacionamentos podero ser utilizados tambm os relacionamentos convencionais da orientao a objetos como, a agregao e generalizao. Relacionamento Notao Relacionamento entre casos de uso exclusivos: casos de uso que so executados sequencialmente (requisitos). Relacionamento entre casos de uso paralelos: casos de uso que so executados concorrentemente com outros casos de uso (requisitos). Relacionamento entre pacotes exclusivos: pacotes que so executados sequencialmente (anlise). Relacionamento entre pacotes parcialmente paralelos: so pacotes que possuem classes executadas de forma concorrente com outras classes de outro pacote (anlise). Relacionamento entre pacotes totalmente paralelos: so pacotes que todas as classes so executadas de forma concorrente com outras classes de outro pacote (anlise). Relacionamento entre pacotes distribudos: so pacotes localizados em diferentes ns do sistema (anlise). R e l a c i o n a m e n t o e n t r e mdulos/subsistemas exclusivos : subsistemas/mdulos que so executados sequencialmente (projeto). Relacionamento entre mdulos/subsistemas parcialmente paralelos: subsistemas/mdulos que tem algumas classes executadas de forma concorrente com outras classes de outro subsistema (projeto). Relacionamento entre mdulos/subsistemas totalmente paralelos: subsistemas/mdulos que todas as classes so executadas de forma concorrente com outras classes de outro subsistema (anlise). Relacionamento entre mdulos/subsistemas distribudos: subsistemas/mdulos localizados em diferentes ns dentro do sistema (projeto). Relacionamento entre objetos exclusivos: objetos que tem seus mtodos executados sequencialmente. Relacionamento entre objetos parcialmente paralelos: objetos que tem alguns mtodos executados concorrentemente. Relacionamento entre objetos totalmente paralelos: objetos que tem todos os seus mtodos executados concorrentemente. Relacionamento entre objetos distribudos: objetos que se encontram localizados em diferentes ns do sistema.
70
3 .2 O A m bie nte D iSE N

Pascutti (2002) define o DiSEN como sendo um ambiente distribudo de desenvolvimento de software, no qual a MDSODI est inserida. O DiSEN tem como um de seus objetivos o de permitir que vrios desenvolvedores, atuando em locais distintos, possam trabalhar de forma cooperativa no desenvolvimento de software, permitindo a interao 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 dinmica que a responsvel pelo gerenciamento da configurao e reconfigurao do ambiente em tempo de execuo; uma camada de aplicao que tem como um dos elementos constituintes o suporte MDSODI, e a camada da infra-estrutura, que prov suporte s tarefas de persistncia, nomeao e concorrncia e, alm disso, incorpora o canal de comunicao.
Supervisor de Configurao Dinmica
Camada dinmica
Repositrio Camada de Aplicao
Gerenciador de Objetos
Gerenciador de Workspace
Gerenciador de Agentes
Canal de Comunicao
Camada de InfraEstrutura
Suporte Tarefa de Persistncia
Suporte Tarefa de Nomeao
Suporte Tarefa de Concorrncia
Middlemiddleware agent
FIGURA 3.2 O AMBIENTE DISEN E SUA ESTRUTURA EM CAMADAS. FONTE (PASCUTTI, 2002).
Abaixo do canal de comunicao, existe uma camada de software bsico do sistema, que ir conter interfaces para hardware especfico, sistema operacional, memria compartilhada e comunicao. O canal de comunicao um elemento fundamental desta arquitetura, pois toda a comunicao entre os elementos constituintes da camada de aplicao e da camada de infraestrutura ser realizada atravs deste canal. constitudo pelo middleware e pelo middleagent, sendo que, quando a comunicao envolver somente objetos, esta ser feita pelo
71
middleware e, quando os agentes estiverem envolvidos, devido s suas propriedades, a comunicao dever ser gerenciada pelo middle-agent. O Supervisor de Configurao Dinmica o responsvel pelo controle e gerenciamento da configurao do ambiente, bem como dos servios que podem ser acrescentados ao ambiente em tempo de execuo. O Gerenciador de Objetos responsvel pelo controle e gerenciamento do ciclo de vida dos artefatos, que pode ser um diagrama, modelo, manual, cdigo fonte, entre outros. O Gerenciador de objetos constitudo por gerenciador de acesso, de atividades, de recursos, de artefatos, de projetos, de processos e de verses e configuraes. Por ser de interesse para o REQUISITE e, por conseguinte, para o nosso trabalho, descreveremos com mais detalhes o gerenciador de recursos. Este o responsvel pelo controle e gerenciamento de recursos para a execuo de uma atividade. Os recursos necessrios para a realizao das atividades podem ser materiais (computador, impressora, sala de reunio) ou ferramentas (programas de computador destinados ao suporte ou automao de parte do trabalho relacionado a uma atividade). Para o DiSEN, a ferramenta REQUISITE considerada como um de seus recursos. O Gerenciador de Workspace responsvel pelo controle e gerenciamento da edio cooperativa de documentos e itens de software e tambm 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 atravs do canal de comunicao e do suporte tarefa de persistncia, conforme a figura 3.3). No caso mais simples consistiria na cpia de um arquivo, porm poderia ser copiada toda uma configurao do repositrio para o workspace, possibilitando o desenvolvedor ter todos os mdulos e documentos necessrios para o funcionamento do sistema a sua disposio localmente. Uma das principais vantagens a de que o desenvolvedor est isolado das alteraes das outras pessoas para o repositrio, 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 modificaes, ele precisa adicionar os mdulos e documentos modificados no repositrio. Esta operao consiste em adicion- las ao repositrio (no caso mais simples), usando a funcionalidade do gerenciador de controle de verso. Entretanto, sabemos que nem sempre ser preciso adicionar todos os arquivos ao repositrio, deste modo, o gerenciador de workspaces deve ser
72
capaz de descobrir quais arquivos foram alterados e ter certeza de que somente estes sero adicionados.
Workspace B Workspace A Gerenciador de Worspace Repositrio Canal de Comunicao Workspace C
Suporte tarefa de persistncia

FIGURA 3.3 REPRESENTAO DO GERENCIADOR DE W ORSPACE (PASCUTTI, 2002)
O Gerenciador de Agentes responsvel pela criao, registro, localizao, migrao e destruio de agentes. O Repositrio responsvel pelo armazenamento dos objetos, verses dos documentos, produtos de software, dados das aplicaes geradas pelo ADS (Ambiente de Desenvolvimento de Software), bem como o conhecimento necessrio para a comunicao entre os agentes.
3 .3 A F e rra me nta RE QU IS ITE

A ferramenta REQUISITE fornece suporte MDSODI, no ambiente distribudo de desenvolvimento DiSEN, na fase de requisitos, considerando aspectos de
concorrncia/paralelismo, distribuio, sincronizao e comunicao. 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 tcnicas baseadas em cenrios. O conceito de cenrios facilmente compreendido pelos diversos stakeholders2 (BREITMAN, 2003, 2004). Deste modo, auxilia no trabalho de entendimento, negociao e validao dos requisitos de sistemas.
O termo stakeholder utilizado para identificar qualquer pessoa que tenha interesse pelo sistema (ROBERTSON & ROBERTSON, 1999). Tambm conhecido como clientes potenciais (SANTANDER, 2002).
73
A REQUISITE completa o comportamento do Universo de Informaes do Sistema (UdI), proporcionando um aumento de qualidade e reduo no tempo e custo da atividade de definio de requisitos.
Elicitao de Requisitos
Validao dos Requisitos
Gerenciamento dos Requisitos
Anlise e Negociao dos Requisitos
Documentao dos Requisitos
FIGURA 3.4 MODELO DE PROCESSO UTILIZADO NA REQUISITE. FONTE (BATISTA, 2003).
A F i g u r a 3.4 apresenta o modelo de processo utilizado na construo da ferramenta REQUISITE que baseado no modelo de processo proposto por Kotonya & Sommerville apud Batista (2003). A elicitao dos requisitos a fase inicial do processo, responsvel por descobrir os requisitos do sistema. As tcnicas de modelagem de casos de uso, cenrios e o Lxico Extendido da Linguagem - LEL (LEITE, 1997) fornecero um modelo das informaes no UdI. Nesta etapa, sero identificados os atores, os casos de uso, os cenrios e LEL. Na anlise e na negociao dos requisitos so analisados os requisitos a fim de se detectarem incompletudes, omisses e redundncias. A documentao de requisitos permite descrever as restries quanto s caractersticas do software, ao processo de desenvolvimento, a interface com outras aplicaes, a descrio sobre o domnio e as informaes de suporte ao conhecimento do problema. Sero produzidos o diagrama de casos de uso, cenrio e LEL. Na fase de validao de requisitos, ser certificado se o documento de requisitos consistente com as necessidades dos usurios. Descrever os requisitos de forma explcita
74
uma condio necessria no somente para validar os requisitos, mas tambm para resolver conflitos entre usurios. 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 confiveis e gerenciveis, aspectos importantes para a obteno de produtos de software de qualidade. Algumas das atividades da gerncia de requisitos incluem rastreamento de requisitos que podem ser executados atravs da explorao dos modelos, utilizando-se, por exemplo, hipertexto.
3 .3 .1 As pe c to s F unc io na is
A ferramenta apia a modelagem de requisitos para a MDSODI, permitindo ao engenheiro de requisitos criar e editar diagramas de casos de uso, cenrios e LEL, bem como rastrear requisitos. A Figura 3.5 apresenta o diagrama de casos de uso da ferramenta REQUISITE.
salvar modelo
criar use case
recuperar modelo Engenheiro de requisitos criar ator
construir diagrama use case explorar modelo construir LEL <<include>> construir cenrio <<include>> construir hipertexto
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:
75
a) Recuperar modelo permite ao engenheiro de requisitos recuperar um
modelo localmente (workspace) ou no ambiente distribudo; b) Salvar modelo

-
permite ao engenheiro de requisitos salvar um modelo
localmente (workspace) ou no ambiente distribudo DiSEN; c) C r i ar 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 so 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 notao da MDSODI so aqueles descritos na Tabela 3.1; e) Explorar modelo
-
esta funcionalidade permite ao engenheiro de
requisitos rastrear os cenrios, entradas do LEL, atores, casos de uso e diagramas de casos de uso;
f) Construir LEL - a engenheiro de requisitos, atravs desta funcionalidade,
poder criar modificar, remover e consultar uma entrada na LEL do modela. A primeira operao diz respeita criao. de uma nova entrad a n a LEL, isto. , a identificao de um smbolo usada na linguagem da UdI. As operaes de modificao e remoo de uma entrada na LEL dizem respeita ao processo de construo 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 notao da MDSODI so aqueles descritos
na Tabela 3.1. h) Construir cenrio - e s t a funcionalidade permite ao engenheiro de requisitos criar, modificar, consultar ou remover um cenrio ao modelo. A primeira operao diz respeito criao e introduo de um novo cenrio. De um modo geral, o resultado da fase de elicitao e que acontece com mais freqncia durante as etapas iniciais do processo. No obstante, novos cenrios podem surgir em qualquer fase de desenvolvimento, pois lembramos que um sistema de
76
software faz parte de um sistema maior e dessa forma, estar sempre sujeita s
mudanas da ambiente ande est inserido. A operao de modificao pode ser definida como um processo de refinamento da informao codificada em um cenrio. medida que progride o desenvolvimento de um sistema, aumenta a compreenso do ambiente onde este ser inserido e de seus requisitos. Durante esse processo, a informao capturada nas fases iniciais vai sendo refinada de modo a refletir, mais precisamente, as necessidades do sistema.
Em conseqncia, o contedo dos cenrios associados sofre modificaes. A operao de retirada consiste na excluso de um cenrio do modelo.
3 .3 .2 A A rquite t ura da R EQ U IS ITE

A arquitetura da ferramenta REQUISITE est apoiada em trs camadas: interface, software base e repositrio. Na camada superior temos o software que faz a interface com os engenheiros de requisitos. Atravs dessa camada, todas as interaes com o sistema so realizadas. Na camada base, temos o software responsvel pelo processamento das informaes, ou seja, a lgica da aplicao. Na camada inferior temos o repositrio que o responsvel pelo armazenamento das informaes, tais como diagrama de casos de uso, atores, cenrios e LEL.
77
A arquitetura detalhada da REQUISITE est representada na Figura 3.6 e as partes constituintes da ferramenta so descritas a seguir:
Interface com Engenheiro de Requisitos
Integrao Casos de uso/cenrios Construo Cenrios Suporte a persistncia de artefatos
Criao Casos de uso
Suporte ao trabalho cooperativo
Construo Hipertexto
Criao Relacionamento Criao Ator
Construo Diagrama de Casos de uso
Construo LEL
Explorar Modelo
Software base
Repositrio
FIGURA 3.6 ARQUITETURA DETALHADA DA FERRAMENTA REQUISITE. FONTE (BATISTA, 2003 ).
a) Interface com o Engenheiro de Requisitos - a responsvel pela comunicao entre o engenheiro de requisitos e a ferramenta, permitindo, com isso, o apoio no processo de requisitos. b) Construo Cenrios - permite as operaes de incluso, modificao e retirada de
um cenrio de um modelo. c) Construo LEL - permite as operaes de incluso, modificao e retirada de uma entrada no LEL.
78
d) ConstruoHipertexto- gera elos de hipertexto entre o LEL e os cenrios. Gera tambm hipertexto entre um termo utilizado no LEL e uma entrada no LEL (princpio da circularidade). Esta construo permite a rastreabilidade entre os modelos. e) Criao de Caso de Uso - permite a adio, a remoo e a modificao de um caso de uso. f) Criao Ator - permite a adio, a remoo e a modificao de um ator. g) Criao do Relacionamento - permite a adio, a remoo e a modificao 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) Construo Diagrama de Casos de Uso - cria e edita diagramas de use case. Isso significa criao, a incluso, a remoo, a modificao e a manipulao de atores, de casos de uso e de relacionamentos no diagrama. i) Integrao de Casos de Uso / Cenrio - cria, remove e modifica uma ligao entre um caso de uso e um cenrio. Atravs desta ligao, pode-se rastrear o cenrio ligado ao caso de uso. j) Explorar Modelo - explora o modelo atravs de uma viso em forma de rvore (TreeExplorer). l) Suporte Persistncia de Artefatos - o suporte persistncia de artefatos permite que um engenheiro de requisitos possa: armazenar, recuperar e remover artefatos de um repositrio de forma transparente. O suporte persistncia torna p o s svel disponibilizar um repositrio de metadados3 no ambiente distribudo de
desenvolvimento de software DiSEN, considerando requisitos que dizem respeito ao acesso aos dados, disponibilidade, controle de verses, escalabilidade, transparncia de localizao, recuperao de falhas, desempenho, sincronizao, atomicidade das operaes e balanceamento de carga entre outros. m) Suporte ao Trabalho Cooperativo - o suporte ao trabalho cooperativo fornecido atravs de elementos de percepo que capturam e condensam as informaes
3
Metadados so considerados dados sobre dados. Podemos encontrar referencias a dados e metadados em Souza (2006).
79
coletadas durante a interao entre os participantes. O suporte ao trabalho cooperativo fornece servios de colaborao, o que torna possvel a comunicao entre os membros do grupo.
3 .3 .3 E xe m plo de Inst nc ia s da R EQ U IS ITE no D iSE N

A seguir, mostramos, na figura 3.7, um exemplo do funcionamento da ferramenta REQUISITE, no ambiente DiSEN.
Engenheiro de Requisitos X Workspace A Ferramenta REQUISITE Interface

Lgica aplicao Acessa/ Modifica
Engenheiro de Requisitos Y Workspace B
Ferramenta REQUISITE Interface

Ferramenta REQUISITE Interface

Repositrio local de artefatos
Repositrio local de artefatos Transfere /atualiza Transfere /atualiza
Repositrio local de artefatos
Repositrio Distribudo de Artefatos
FIGURA 3.7 ESQUEMA DE INSTNCIAS DA FERRAMENTA REQUISITE. FONTE (BATISTA, 2003).
No Workspace A, temos o Engenheiro de Requisitos X, com duas instncias da ferramenta REQUISITE em execuo no DiSEN. No Workspace B, ternos o Engenheiro de Requisitos Y, com uma instncia da ferramenta REQUISITE em execuo no DiSEN. Cada instncia da ferramenta REQUISITE utiliza um repositrio de artefato local no seu workspace e pode acessar, quando desejar, artefatos de um repositrio de artefato distribudo no DiSEN. Quando, por exemplo, o Engenheiro de Requisitos Y desejar alterar um artefato que est no repositrio distribudo, no caso mais simples, os servios de suporte persistncia do DiSEN fazem uma cpia deste modelo e o transfere para o repositrio loca1. Aps o
80
trmino de seu trabalho, quando desejar, no caso mais simples, o Engenheiro de Requisitos Y ativa os servios de suporte persistncia do DiSEN e este atualiza o modelo no repositrio distribudo. Desse modo, um grupo de stakeholders podem agregar diferentes tipos de conhecimentos, habilidades e solues e contribuir para que as atividades, sejam finalizadas com um desempenho positivo.
Workspace 1 Aplicaes Workspace N Aplicaes
Camada de Aplicao (ferramentas)

Gerenciador de Objetos Gerenciador de Agentes Supervisor de Configurao dinmica Gerenciador de Workspace
Repositrio
Camada de Gerenciamento de Aplicao (distribuio/coordenao)

Suporte persistncia Suporte nomeao Suporte transao Suporte Agentes
Camada de Abstrao de Middleware
CORBA
JINI
RMI
Middleware Plataforma (Sistema Operacional, Computadores, Equipamentos de Rede)

FIGURA 3.8 REPRESENTAO DA ARQUITETURA DO DISEN. FONTE (BATISTA, 2003).
Na representao dos elementos da arquitetura do DiSEN, ilustrado na figura 3.8, destacamos que, em um workspace, na Camada de Aplicao, podem ser executadas vrias aplicaes. Como exemplo, podemos citar: a prpria ferramenta REQUISITE, o Distributed Software Manager - DIMANAGER (PEDRAS, 2003) e/ou vrias instncias da mesma aplicao como mostrado acima na Figura 3.7.
81
3 .4 Re s umo do Ca pt ulo
Este captulo 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, porm, importante salientar que propriedades a principal caracterstica que buscamos obter ao desenvolvermos um projeto de software, ou seja, sempre esteve presente em nossos projetos. Porm as propriedades transversais eram impossveis de se mapear com as tcnicas existentes at ento (CHITCHYAN et al, 2005). Por este motivo, a ferramenta REQUISITE no est apta a identificar e representar estas propriedades transversais (ou aspectos) utilizando a metodologia e a abordagem aplicada a ela. No prximo captulo ser apresentado uma nova abordagem para a Engenharia de requisitos: a DAORE Distributed Aspect Oriented Approach for Requirements Engineering.
4. A Abordagem DAORE
82
CAPTULO
4
A ABORDAGEM DAORE
A melhor forma de prever o futuro cri-lo. Peter Drucker
int eres s ante obs ervar c omo as melhores id ias s urge m de repente, foi as s im c om algumas inven es e outras foram atra vs de tentat iva e erro. Reza a lenda que Thomas Alva Eds on, o inventor de vrias cois as , dentre e las a l mpada, c erta feit a reuniu s eus c olaboradores para uma fes ta. Ao c hegare m, e s em s aberem qua l a razo da c omemora o, perguntara m a e le que mot ivos tinha para fazer uma c omemora o, ao que Eds on respondeu: "c omemoro o dc imo mils imo frac as so na minha tentat iva de inventar a l mpada". Como ass im? Pergunta ra m os pres entes . Como pode algum c omemorar dez mil fr ac as sos ? Simples , meus c aros , respondeu Edson: "Sou a nic a pes soa no mundo que c onhec e dez mil mane iras difere ntes de c omo no fazer uma l mpada! Is so merec e uma c omemora o!". Na dc ima mils ima prime ira t enta t iva e le inventou a lmpada!
83
Ana loga mente ao des envolvime nto de s is temas , temos proc urado obs ervar outras c inc ias e trazer a lguns conc eitos para, no m nimo, fac ilitar nos s a c ompreens o sobre o problema e formular s olu es . Porm, s abemos que um mes mo s is tema de s oftwar e para empres as difer entes requer pequenas modif ic a es (nos c asos mais s imples ) e, s vezes , grandes mudan as . Des te modo, o des envolvime nto de s is temas de s oftware, ma is partic ula rme nte o que c ha mamos de Enge nha r ia de Requis itos c ompreende uma das ma is c omple xas at ividades da Enge nhar ia de Software. Dura nte o proc es so foram pesquis adas e utilizadas vr ias s olu es , porm s empre haver o aperfei oamento de mtodos , busc ando uma me lhor ia c ont nua. A abordagem propos ta a s eguir bus c a exatamente is s o: uma s olu o para alguns problemas (dentre os muitos ) da rea de Engenhar ia de Requis itos Orient ada a As pec tos .
4 .1 O bje t iv o s e D ire t rize s P rinc ipa is

A Abordagem DAORE Distributed Aspect Oriented Approach for Requirements Engineering, tem como principal objetivo facilitar a identificao de aspectos candidatos nas fases iniciais do processo de desenvolvimento de sistemas. Para isso, se utiliza de conceitos e ferramentas grficas de algumas abordagens existentes (as estudadas no Captulo 2), alm 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
84
Caractersticas Relacionamento entre aspectos e requisitos funcionais Viewpoint Adaptado para requisitos no funcionais e funcionais
Abordagens AORE Estudadas Goals Use Case
Theme/Doc
Operacionalizaes de requisitos no funcionais
Adaptado para estratgias de satisfao. Utiliza-se este conceito tambm nos requisitos organizacionais. Adaptado de Clarke&Baniassad (2005) Utiliza-se o modelo proposto por Souza (2004) Utiliza-se o modelo proposto por Souza (2004)
Identificao dos aspectos Composio dos aspectos
Resoluo de conflitos nos aspectos
No captulo 2 foi feita uma comparao entre estas abordagens e partindo desta premissa definimos algumas diretrizes que a DAORE deve possuir: A - Suporte a metodologia MDSODI na definio dos cenrios e das propriedades transversais pois esta metodologia a utilizada pelo ambiente DISEN e pela ferramenta REQUISITE, por este motivo a abordagem recebeu em sua definio o nome de Distributed; o Para tornar esta correlao mais clara nos projetos foi identificado nos cenrios o seu tipo de acordo com a proposta da MDSODI; e o Esta identificao facilita a forma de tratamento dos cenrios nas fases seguintes ao desenvolvimento. B - Permitir um alto grau de usabilidade (de acordo com o conceito introduzido pela Tabela 3.9 do Captulo 3);
4. A Abordagem DAORE C - Boa adequao quanto identificao de propriedades transversais;
85
D - Facilitar a identificao de propriedades transversais no-funcionais, derivados de requisitos no funcionais, a partir do trabalho do Cysneiros (2001) e das normas ISO/IEC 9126;
E - Identificar e modelar requisitos organizacionais, atravs de suas operacionalizaes (quando pertinentes ao domnio);
F - Aumentar a apreensabilidade atravs da identificao das propriedades transversais;
G Especificar XML Schemas 1 para auxiliar na exportao de documentos padro no formato XML (smbolos do LEL, cenrios, aspectos e ontologias), a fim de aumentar a interoperabilidade entre ferramentas utilizadas pela MDSODI;
H - Facilitar a resoluo de conflitos manualmente atravs de padres de domnio pr-estabelecidos reuso de especificaes e ontologias2 de requisitos utilizando o LEL, e
I Facilitar o rastreamento de requisitos atravs do principio de circularidade (utilizado no LEL) e vocabulrio mnimo. A Tabela 4.2 apresenta a relao das diretrizes em relao s caractersticas de
qualidade apresentadas na Tabela 2.8 e 2.9 do Captulo 2. O seu preenchimento est de acordo com as definies apresentadas anteriormente. Assim foi feito atribuio das diretrizes onde elas melhor se aproximavam da definio.
Alguns XML Schemas esto especificados pela W3C em www.w3c.org , porm no h especificao para requisitos e o LEL. 2 Alguns conceitos de ontologias podem ser encontrados em Breitman (2005).
86
TABELA 4.2 . RELAO ENTRE D IRETRIZES DA DAORE E AS CARACTERSTICAS DE QUALIDADE
Caracterstica
Funcionalidade
Confiabilidade Usabilidade
Eficincia
Manutenibilidade
Portabilidade
Sub-caracterstica Abrangncia Adequao Acurcia Interoperabilidade Conformidade Maturidade Artefatos Apoio Case Inteligibilidade Apreensibilidade Resoluo de Conflitos Tratamento de Requisitos Organizacionais Requisitos funcionais aspectos Requisitos no funcionais aspectos Rastreabilidade Analisabilidade Modificabilidade Testabilidade Adaptabilidade Capacidade para ser instalada Capacidade para substituir
Diretriz A C D, G G D, G, H F A, D,G A, B,C,D e G A, B, D, E, H F H E F D, F I H I A G G A
Como podemos observar na tabela 4.2, nos itens: Abrangncia: foi atribuda a diretriz A, pois como a abordagem deve apoiar a MDSODI na fase de requisitos. Adequao: foi atribuda a diretriz C, pois deve possuir boa adequao quanto a identificao e composio de propriedades transversais. Acurcia: foram atribudas a s diretrizes D e G, pois deve facilitar a identificao de propriedades e dos requisitos no funcionais atravs de ontologias sugeridas por Cysneiros (2001), alm de definir padres para permitir a importao de documentos. Interoperabilidade: foi atribuda a diretriz G, pois deve possuir a capacidade de interagir com ferramentas diferentes atrav s d a importao de documentos seguindo uma padronizao.
87
Conformidade: foram atribudas as diretrizes D,G e H, pois a conformidade diz respeito a padres e, sendo assim, deve estar de acordo com o estabelecido.
Maturidade: foi atribuda a diretriz F, pois o aprendizado atravs do auxilio da identificao de propriedades proporcionada pela abordagem permite o aumento de maturidade uma vez que pode ser feito de forma semi-automtica.
Artefatos: foram atribudas as diretrizes A,D e G, pois contm os artefatos previstos para a definio do LEL, alm de ontologias de requisitos no funcionais e de documentos XML.
Apoio Case: foram atribudas as diretrizes A,B,C,D e G, pois deve oferecer suporte a metodologia MDSODI na construo dos cenrios, na especificao dos propriedades transversais, nos requisitos no funcionais, na utilizao da abordagem e na confeco de documentos XML.
Inteligibilidade: foram atribudas as diretrizes A,B,D,E e H, pois os conceitos e definies da abordagem sero mais consistentes e mais fceis de compreender se for feito de forma semi-automtica (de preferncia de forma automtica), assim est ligada ao item anterior tambm.
Apreensibilidade: foi atribuda a diretriz F, pois o objetivo principal da abordagem est na facilidade de identificao dos propriedades transversais, porm podemos atribuir o item anterior tambm.
Resoluo de Conflitos: foi atribuda a diretriz H. Infelizmente a resoluo de conflitos deve ser realizada de forma manual, mas podemos identificar os conflitos de forma automtica.
Tratamento de Requisitos Organizacionais: foi atribuda a diretriz E, pois deve permitir a integrao dos requisitos organizacionais com os requisitos funcionais atravs de suas operacionalizaes.
88
Requisitos funcionais aspectos: foi atribuda a diretriz F, pois deve possuir diretrizes para nortear a identificao dos requisitos funcionais como propriedades transversais.
Requisitos no funcionais aspectos: foram atribudas as diretrizes D e F, pois deve possuir diretrizes para nortear a identificao dos requisitos no funcionais como propriedades transversais.
Rastreabilidade: foi atribuda a diretriz I, pois atravs do principio de circularidade do LEL podemos realizar o rastreamento de requisitos.
Analisabilidade: foi atribuda a diretriz H, pois atravs da resoluo de conflitos podemos identificar possveis falhas na composio das propriedades transversais.
Modificabilidade: foi atribuda a d i r e t r i z I, p o i s atravs do rastreamento permitido pelo principio de circularidade do LEL podemos identificar e atualizar mais rapidamente as informaes, bem como analisar e detectar possveis erros.
Testabilidade: foi atribuda a diretriz A, pois deve estar de acordo com a MDSODI na definio dos cenrios a fim de permitir o seu uso. Podemos tambm identificar uma forte ligao com o Apoio Case para o cumprimento desta caracterstica.
Adaptabilidade: foi atribuda a diretriz G. A adaptabilidade diz respeito a instalao, mas como estamos lidando com abordagem podemos dizer que esta deve ser capaz de se adaptar a novos ambientes com o mnimo de esforo. Este princpio pode ser satisfeito com a exportao de documentos em XML.
Capacidade para ser instalada: foi atribuda a diretriz G, pois pode ser exportado o documento XML para ser importado em outro ambiente.
Capacidade para substituir: foi atribuda a diretriz A, pois deve possuir integrao com a MDSODI com o mnimo esforo na mudana ocorrida.
89
4 .2
O P ro c e sso de De se nv o lv ime nto P ro po sto

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), porm com algumas adaptaes para incorporar os trabalhos de Cysneiros (2001) e Breitman (2003, 2005), alm de incorporar a definio de aspectos candidatos para abranger as diretrizes propostas anteriormente.
Construo de Requisitos
Construo do LEL
Definio de Aspectos Candidatos
Mapeamento de Ontologias
FIGURA 4.1 . MODELO DE PROCESSO DA ABORDAGEM DAORE
De modo geral as fases de desenvolvimento do processo especificadas na figura 4.1 esto descritas como se segue: Fase 1 - Construo de Requisitos deve-se seguir a construo dos requisitos funcionais, no funcionais e organizacionais; Fase 2 - Construo do LEL deve-se seguir a construo dos termos do LEL e dos cenrios elicitados; Fase 3 Definio 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 padro proposto por Breitman (2005). As fases 3 e 4 independem uma da outra, podendo ser construdas em paralelo.A seguir descreveremos o processo de construo de cada fase.
90
4 .2 .1 F a se 1 Co nst ru o de Re quis ito s

De um modo geral na construo dos requisitos devemos identificar os requisitos organizacionais (dizem respeito a metas da empresa, suas polticas estratgicas adotadas, os relacionamentos entre os seus atores junto com seus respectivos objetivos), requisitos funcionais (definem a funcionalidade do sistema) e requisitos no funcionais (dizem respeito a questes de qualidade e segurana, de maneira geral).
4.2.1.1 - Levantamento dos Requisitos A construo de requisitos segue o modelo proposto por Kotonya et al apud Santander (2002), figura 4.2.
Levantamento dos requisitos
Utilizao de tcnicas tradicionais

Anlise e Negociao
Refinamento dos Requisitos e Entendimento do Problema Lista Requisitos Refinados
Lista Requisitos iniciais
Validao com cliente
Est satisfeito
Requisitos do Sistema
FIGURA 4.2 PROCESSO GERAL DE CONSTRUO DE R EQUISITOS
Podemos observar que o processo geral de construo de requisitos (figura 4.2) inicia-se com o levantamento dos mesmos atravs de tcnicas tradicionais como entrevistas, cenrios (HADAD et al. 1999) (HAUMER et al. 1998) (LEITE et al. 1997) (BREITMAN et al. 1998); observao e anlise social (GOGUEN et al. 1993); etnografia (SOMMERVILLE et al. 1999); entre outras. Toda tcnica de elicitao deve descrever os requisitos atravs de uma representao facilmente entendida por todos os stakeholders (SANTANDER, 2002).
91
Aps a elicitao dos requisitos eles devem ser analisados para detectar incompletudes, omisses ou redundncias. Na anlise, a preocupao est em descobrir os requisitos que realmente so necessrios e que o stakeholder deseja. Santander (2002) descreve ainda algumas tcnicas utilizadas para realizar anlise dos requisitos. Santander (2002) define a negociao 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 negociao consiste em que todos os stakeholders entrem em consenso em relao a um conjunto de requisitos definidos, bem como em relao s prioridades definidas para os mesmos. A atividade de validao de requisitos a ltima atividade para certificar-se que o documento final de requisitos satisfaz em todos os aspectos o que o usurio deseja do sistema. Santander (2002) descreve tcnicas de validao onde so refinados os requisitos at que tenhamos uma lista dos requisitos acordados. Em nosso trabalho exploraremos um pouco mais os conceitos referentes aos requisitos no funcionais e organizacionais, uma vez que os requisitos funcionais so mais simples de serem identificados, mesmo porque, a razo de existncia do projeto a ser desenvolvido. 4.2.1.2 - Construo de Requisitos Funcionais Os requisitos funcionais dizem respeito definio das funes que um sistema ou um componente de sistema deve fazer. Eles descrevem as transformaes a serem realizadas nas entradas de um sistema ou em um de seus componentes, a fim de que se produzam sadas (SANTANDER, 2002). A identificao dos requisitos funcionais pode ser realizada seguindo tcnicas existentes para a elicitao de requisitos: entrevistas, cenrios (LEITE et al., 1997) (HADAD et al., 1999) (HAUMER et al., 1998) (BREITMAN & LEITE, 1998), observao e anlise social, entre outras. Neste trabalho segue a tcnica de cenrios proposto por (LEITE et al., 1997). 4.2.1.3 - Construo de Requisitos no-Funcionais A identificao de requisitos no funcionais diz respeito, geralmente, a questes de qualidade e segurana. A sua identificao pode ser realizada tendo por base as caractersticas de qualidade do software, definidos por meio da ISO/IEC 9126 (ISO,
92
2006). Assim podemos definir para nossos projetos, baseados no domnio da aplicao, caractersticas afins e sub-caractersticas, perfazendo um banco de ontologias de domnio para requisitos no funcionais. A autora deste trabalho acredita que, por exemplo, se definirmos inicialmente um conjunto de requisitos no funcionais baseados em um domnio de uma aplicao mdica, bem provvel que sejam utilizados em uma outra aplicao de um mesmo domnio. Assim, o trabalho do Engenheiro de Requisitos pode ser apoiado por este poderoso aliado na elucidao de requisitos no funcionais. Algumas classificaes dos RNFs podem ser encontradas na literatura: (MAMANI, 1999), (SOMMERVILLE, 92) e (CYSNEIROS, 2001). Neste trabalho iremos utilizar a classificao do Cysneiros, por se utilizar do Chung (2000) e das normas ISO/IEC 9126, para construo de nosso banco de requisitos no funcionais. Um fator muito importante na elicitao dos requisitos no funcionais que so 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 classificao proposta por Cysneiros elaborando a decomposio dos RNF em operacionalizaes resulta em um trabalho mais minucioso. Cysneiros (2001) prope uma taxonomia que classifica os RNFs em primrios e especficos (ver figura 4.3). RNFs primrios so aqueles mais abstratos que representam propriedades como: Confiabilidade, Rastreabilidade, Preciso, Segurana. J os RNFs especficos so decomposies que se seguem aos RNFs primrios e tendem a diminuir o nvel de abstrao de um determinado RNF, e portanto, atingir um nvel de granularidade no tratamento da informao mais detalhado. Um exemplo desta classificao seria o RNF Primrio Confiabilidade que pode ser decomposto em validao, autorizao e entrega do software. RNFs primrios podem ser decompostos em outros RNFs secundrios at que se chegue ao que Chung (CHUNG, 2000) chama de operacionalizao dos RNFs. Uma operacionalizao de um RNF uma ao ou informao que ir garantir a satisfao do RNF.
93
Cysneiros (2001) exemplifica o caso de um sistema de informao para laboratrios de anlises clnicas. A entrega do laudo ao paciente possui um RNF de confidencialidade que seria seu RNF primrio. Para que possamos detalhar o que isso implica, temos de decompor este RNF em um RNF especfico de segurana operacional que por sua vez poderia ser decomposto na operacionalizao solicitar carteira de identidade. Ou seja, para satisfazer o RNF confidencialidade teramos de prever uma ao no sistema, que garantisse que o funcionrio que entregou o laudo solicitou a carteira de identidade ao paciente antes de entregar-lhe o laudo.
Performance ** Clareza da Informao Custo Seguro Qualidade Restries Operacionais Restries Fsicas Manutenabilidade
Tempo real Restries de tempo Outras
**
RNFs Dinamicos
Portabilidade ** ** **
Fcil de achar onde est um erro Fcil de modificar Estve Fcil de testar
Adaptabilidade Fcil de migrar por plataformas Fcil de aprender Fcil de Usar (interface adequada) Equipamento/Informao necessrio Integridade Maturidade dispnvel quando
Usabilidade
Confiabilidade
RNF Primrio
RNF Especfico
Numerica Informao correta sempre disponvel
Preciso Rastreabilidade Confidencialidade
Caminho feito por algo/algum Qual o estado no momento
RNF Esttico
Qualidade Confiabilidade
Identidade confirmada Dados privados no espostos Tipo de equipamento a ser utilizado Ordens de exibio especficas Validao Autoriazao Entrega Permisso para consultar/atualizar informao
Segurana Confidencialidade de dados
** ISO 9126
FIGURA 4.3 UMA TAXONOMIA PARA RNFS . FONTE: CYSNEIROS(2001)
94
De acordo com a figura 4.3, Cysneiros separa os RNFs em estticos e dinmicos. RNFs estticos so aqueles que, quando presentes, normalmente requerem o uso de dados para valid- los como, por exemplo: segurana, preciso e rastreabilidade. RNFs dinmicos, por outro lado, usualmente representam conceitos mais abstratos, que normalmente envolvem aes ou critrios de qualidade como, por exemplo:
Qualidade, performance, manutenibilidade, restries operacionais. Alguns RNFs podem ser tanto estticos quanto dinmicos dependendo do contexto do domnio que estejam inseridos. A Figura 4.3 mostra um resumo desta taxonomia que tambm pode ser utilizada como um checklist para a elicitao 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 primrios e secundrios do sistema, bem como sua estratgia de satisfao, Influncia (I) e uma observao indicando o porque da influencia positiva(+) ou negativa (-) da estratgia de satisfao no RNF. Cysneiros (2001) afirma ainda que esta lista no pretende ser completa, mas sim, um ponto de partida para cada desenvolvedor gerar seu prprio conhecimento a respeito de RNFs, podendo inclusive adicionar outros.
TABELA 4.3 RNFS E ESTRATGIAS DE SATISFAO. FONTE: CYSNEIROS(2001).
RNF Primrio
RNF Especfico
Estratgia Satisfao
Informao de apoio validao
I
+
Observaes
caso as informaes de apoio sejam utilizadas para a obteno de preciso de valor de outros itens de informao. pois a inspeo das informaes por uma pessoa diferente do emissor aumenta a possibilidade de descobrir valores incorretos destas informaes. caso os itens de informao recuperados e verificados tenham uma preciso de valor duvidosa. pois inspeciona itens de informao em relao a informaes de apoio para verificar se esto corretos. caso sejam adotados procedimentos para impedir que itens de informao assumam valores fora da faixa ou para autorizar que itens de informao tenham valores fora da faixa. caso o aviso chame ateno sobre itens de informao com valor duvidoso. pois a presena de um autorizador dificulta
PRECISO DE VALOR
PRECISO
Preciso auditoria Validao automtica Faixa de valores
Aviso - Valor impreciso autorizao
+ +
95
que itens de informao incorretos sejam transmitidos para o sistema de informao. pois a capacidade/nvel de confiana do ator do UdI aumenta a preciso de valor dos itens de informao que manipula pois os itens de informao indicados so comparados para verificar sua correo. caso se indique aes que possibilitam evitar valores incorretos pois os itens de informao com preciso de valor duvidosa so verificados em suas fontes caso as restries de integridade estejam relacionadas com preciso de valor de itens de informao. caso as informaes de apoio sejam utilizadas para a obteno de preciso de valor de outros itens de informao. caso seja necessrio um tempo excessivo para a validao. caso os itens recuperados e verificados tenham uma preciso de oportunidade duvidosa. pois mais rpida do que a validao convencional. caso a validao das regras de acesso seja demorada. caso aviso chame ateno sobre itens de informao que esto atrasados para serem divulgados ou repassados caso o processo de autorizao sejam demorado ou o autorizador no esteja sempre disponvel para realizar a autorizao. pois a definio de prazos aumenta a probabilidade dos itens de informao serem indicados no tempo correto. caso se indiquem aes que possibilitem evitar atrasos na indicao de itens de informao caso as informaes de apoio sejam utilizadas para a obteno de preciso de propriedade de outros itens de informao. pois a inspeo das informaes por uma pessoa diferente do emissor aumenta a possibilidade de descobrir propriedades desejadas destas informaes, que no esto presentes. caso os itens de informao recuperados e verificados tenham uma preciso de propriedade duvidosa. pois inspeciona itens de informao, utilizando informaes de apoio, para verificar se possuem determinadas propriedades. caso sejam adotados procedimentos, como por exemplo autorizao, para garantir certas propriedades de itens de informao que estejam fora da faixa.
Capacidade de executar tarefa confirmao Pr-aviso de valor impreciso Validao na fonte Checar consistncia Apoio a informao validao Preciso auditoria Preciso de oportunidade Validao automtica Validao de acesso Aviso de valor impreciso autorizao
+ + +
+ +
calendrio
Pr-aviso de valor impreciso Apoio a informao validao Preciso de propriedade
Preciso auditoria Validao automtica
Faixa de valores
autorizao
96 + pois a presena de um autorizador dificulta

que itens de informao, que no possuem uma propriedade desejada, sejam transmitidos para o sistema de informao. pois a capacidade/nvel de confiana do ator do UdI aumenta a preciso de propriedade dos itens de informao que manipula caso se indiquem aes que possibilitem evitar que certas propriedades no estejam presentes em itens de informao pois os itens de informao com preciso de propriedade duvidosa so verificados em suas fontes caso as restries de integridade estejam relacionadas com alguma(s) propriedade(s) de itens de informao que se deseja alcanar onde a propriedade desejada qualidade de impresso de itens de informao. caso se indique aes que possibilitem evitar que os itens de informao no estejam refletindo seus valores do mundo real caso o validador no possa ter acesso s informaes validadas. pois, com a identificao e autenticao das identidades dos atores do UdI, pode-se permitir o acesso s informaes, recursos, e/ou atores do UdI apenas para os atores que tem permisso para tal. caso os auditores no possam ter acesso s informaes recuperadas e verificadas. pois limita o tempo para acessar itens de informao pois permite identificar acessos no autorizados a itens de informao. pois permite a deteco de acessos no autorizados a itens de informao. pois os itens de informao so acessados apenas por quem tem direito para tal. pois permite detectar acessos no autorizados a itens de informao. pois, com a identificao, possvel permitir o acesso s informaes, recursos e/ou atores do UdI apenas para os atores que tem permisso para tal pois, com a autenticao, pode-se permitir acesso s informaes, recursos e/ou atores do UdI apenas para os atores do UdI que tem permisso para tal e asseguram suas identidades pois, com a identificao e autenticao das identidades dos atores do UdI, pode-se permitir a alterao de informaes apenas para os atores que tem permisso para tal. pois limita o tempo para alterar itens de informao. pois permite identificar alteraes no autorizadas a itens de informao.
Capacidade de executar tarefa Pr-aviso de valor impreciso Validao na fonte Checar consistncia
+ + + +
Consistncia externa
Qualidade impresso Pr-aviso de valor impreciso
+ +
validao Identificao/auto rizao
confidenciabilidade
Preciso auditoria Tempo limitado de acesso Histrico de acesso alarme Validao de acesso Segurana auditoria identificao
+ + + + + +
segurana
autenticao
integridade
Identificao/ autorizao
Tempo limitado de acesso Histrico de acesso
+ +
Alarme Validao de acesso Segurana auditoria identificao
97 + pois ajuda na deteco de alteraes no

autorizadas de itens de informao.
+ pois os itens de informao so alterados +

+ somente por quem tem direito para tal. pois permite detectar alteraes no autorizadas de itens de informao. pois, com a identificao, pode-se permitir a alterao de itens de informao apenas para atores do UdI que tem permisso para tal pois, com a autenticao, pode-se permitir alterao de informaes apenas para os atores do UdI que tem permisso para tal e asseguram suas identidades pois os servios do sistema de informao so suspensos aps um determinado tempo. caso sejam necessrias vrias identificaes e autenticaes. caso os avisos sejam freqentes, atrapalhando a utilizao dos servios do sistema de informao por atores do universo de informaes. caso o mesmo ator do UdI deva informar duas vezes o mesmo item de informao. caso seja necessrio realizar a identificao vrias vezes. caso seja necessrio realizar a autenticao vrias vezes. caso sejam adotados procedimentos que avisem que valores de itens de informao digitados esto fora da faixa. pois o ator do universo de informaes tem conhecimento e/ou nvel de confiana para executar ao.
autenticao
Disponibilidade
Tempo limitado de acesso Identificao/ autorizao Aviso de impreciso
Usabilidade
rapidez
confirmao identificao autenticao
Taxa baixa de erros confiabilidad e Confiabilidade na execuo de tarefas
Faixa de valores
Habilidade na execuo de tarefas auditoria autorizao
- caso seja necessrio a contratao de

pessoas para realizar a auditoria.
- caso seja necessrio a contratao de pessoas para realizarem o papel de autorizadores. caso seja necessrio contratar mais pessoas que tenham o conhecimento e/ou confiana para executar as aes.
Custo operacional
custo
Capacidade na execuo confirmao Validao na fonte Qualidade na impresso Histrico de acesso Segurana auditoria Apoio a informao Histrico de acesso
- caso o contato com a fonte dos itens de

informao seja caro
- caso os recursos, utilizados para atingir

qualidade de impresso, sejam caros. caso seja demorado o registro das informaes do histrico. caso a manuteno do histrico acarrete uma diminuio na rapidez dos servios prestados pelo sistema de informaes. caso as informaes de apoio sejam numerosas. pois registra o autor de consultas e alteraes de itens de informao, bem como quando aconteceram as consultas e alteraes
Tempo de performance performance
Espao performance Tempo e local rastreabilidade
98
A tabela 4.3 apresentou uma ontologia de requisitos no funcionais, indicando a influncia da estratgia de satisfao utilizada para atender ao requisito de forma geral, ou seja, se possui uma influncia negativa (-) ou positiva (+). Se houver a necessidade, ao final das operacionalizaes dos requisitos no funcionais, uma tabela pode servir de apoio para o mapeamento dos requisitos no funcionais e funcionais, conforme pode ser verificado na Tabela 4.4.
TABELA 4.4 . MAPEAMENTO DOS REQUISITOS NO FUNCIONAIS E REQUISITOS FUNCIONAIS
Requisitos No Funcionais
RNF1 RNF2 ... RNFn
Requisitos Funcionais RF1 RF2 ... RFn X X
Cysneiros (2001) relaciona as operacionalizaes dos requisitos no funcionais ao LEL a partir de seus smbolos (ou termos), porm relacionaremos ao construirmos os cenrios, pois na construo dos cenrios isso repetido. Esta tarefa ser explicada com mais detalhes ao verificarmos a fase 3 Construo do LEL.
4.2.1.4 - Construo de Requisitos Organizacionais Geralmente a Identificao de Requisitos Organizacionais descartada, porm j se tem trabalhos salientando a importncia de sua elaborao e integrao na modelagem funcional (SANTANDER, 2002). O conhecimento do ambiente organizacional permite definir como o sistema de software pretendido ir satisfazer os objetivos da organizao, porque ele necessrio, quais as alternativas existentes e quais as implicaes das alternativas para as vrias partes interessadas, entre outros aspectos (SANTANDER, 2002). Toranzo (2002) expe que os objetivos dos modelos organizacionais so:
1) Entender a estrutura e a dinmica da organizao que hospedar o sistema; 2) Entender os problemas da organizao e identificar as suas solues;
3) Obter uma nica e melhor compreenso da organizao; 4) Contribuir para derivar requisitos do sistema para apoiar a organizao.
99
Portanto, uma cuidadosa ateno aos aspectos organizacionais crucial para o sucesso do sistema de informao de uma organizao (YU, 1997).
A incluso da modelagem organizacional torna explcito o fato de que podem existir alguns conceitos organizacionais que so importantes para identificar e conhecer as implicaes sobre os requisitos dos sistemas. Santander (2002) argumenta que a viso 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 organizao e outras propriedades relacionadas com o desempenho, segurana e restries. De qualquer forma, os requisitos organizacionais so importantes porque auxiliam a compreenso de interaes complexas entre as organizaes e pessoas envolvidas. No RUP Rational Unified Process, a modelagem organizacional est definida no Workflow de Modelagem de Negcio, cujo objetivo principal est em modelar a organizao. Para isso define o modelo de casos de uso de negcio e o modelo de objetos de negcio. O modelo de casos de uso de negcio representa as funes de negcio desejadas. Consiste de atores e casos de uso no nvel de negcio. Os atores representam papeis externos em relao a um negcio e casos de uso de negcio so processos. O modelo de objetos de negcio inclui realizaes de casos de uso, as quais mostram como casos de uso de negcio so executados, em termo de interaes de trabalhadores de negcio e entidades de negcio. O modelo de negcios e o modelo de casos de uso de negcio podem auxiliar na identificao da relevncia destes aspectos. Algumas situaes so mais visveis para identificar quando um requisito organizacional relevante para o sistema de software a ser desenvolvido. Por exemplo, a gerncia de um supermercado pode decidir que o sistema de venda de produtos
100
implantado, dever incluir um processo de atribuio de pontos aos clientes que possuam o carto de fidelidade do supermercado. Assim, identificar os requisitos organizacionais, suas prioridades, suas expectativas em relao ao sistema podem levar definio de algumas funcionalidades na qual o sistema deve atender para que possa satisfazer estes requisitos organizacionais. Estas funcionalidades dizem respeito a uma restrio ou influncia em relao a uma funcionalidade bsica. Uma maneira mais simples de identificao seria aps a identificao dos requisitos organizacionais (e sua possvel decomposio) formular algumas perguntas chaves, como: 1) Este requisito influencia outros requisitos? Quais? 2) Ele possvel de implementao? Assim, ao determinar os requisitos organizacionais do sistema e sua possvel operacionalizao fica mais fcil identificar quais requisitos sero afetados se existir um mapeamento dos requisitos organizacionais com os requisitos funcionais e no funcionais, como podemos observar na tabela 4.5.
TABELA 4.5 MAPEAMENTO DOS REQUISITOS ORGANIZACIONAIS EM R EQUISITOS FUNCIONAIS E NO
FUNCIONAIS
Requisitos Funcionais Requisitos Organizacionais RF1 RF2 ...

RO1 RO2 ... ROn
Requisitos no funcionais R2 ... Rn
RFn R1 X
X X
4 .2 .2 F a se 2 Co nst ru o do LEL
Este recurso foi implementado na ferramenta REQUISITE e ser, igualmente, utilizado na abordagem DAORE. O principal objetivo do Lxico Ampliado da Linguagem (LAL) ou Lxico Extendido da linguagem (LEL) o de registrar a linguagem utilizada pelos atores do UdI,
4. A Abordagem DAORE sem contudo se preocupar com a
101 funcionalidade (FRANCO&LEITE, 1 9 92)
(LEITE&FRANCO, 1993). De modo geral o LEL define os seguintes passos a serem realizados: 1) Elicitao de requisitos separar perodos compostos em oraes simples, transformar oraes na voz passiva para voz ativa e formas substantivas de verbos para formas verbais correspondentes. 2) Identificao dos smbolos palavras ou frases com significado especial, procurando por sujeitos, verbos, objetos e estados (predicativos). 3) Classificao dos smbolos identificados 4) Descrio dos smbolos criar entradas no LEL referentes aos smbolos identificados. O modelo de processo do LEL apresentado na Figura 4.4.
Requisitos do Sistema
Formatar texto
Identificao dos smbolos Incluso, Classificao e descrio dos smbolos
Texto formatado
No
Verificar consistncia
Sim Sim No
Verificar consistncia Incluir Cenrios
No Sim
Incluir Restries? Acabou cenrios
Analisar Interdependncias e Resolver conflitos
FIGURA 4.4 MODELO DE PROCESSO DE CONSTRUO DO LEL NA ABORDAGEM DAORE
Seguindo o processo proposto na construo do LEL na figura 4.4 podemos observar que:
4. A Abordagem DAORE 1. O processo se inicia com a formatao dos requisitos elicitados;
102
2. feito a identificao dos smbolos do LEL de acordo com o modelo proposto por (LEITE, 1997); 3. A incluso de cenrios feita de forma trivial seguindo orientao de construo de cenrios a partir do LEL da linguagem (LEITE, 1997); 4. A incluso de restries3 : (RNF e RO) realizada aps a construo de cenrios. Porm, podemos incluir estas restries durante a sua construo; 5. Adaptamos a proposta de Cysneiros (2001) incluindo os requisitos no funcionais (que fazem parte das restries de qualidade do sistema) aps a incluso de todos os cenrios ou em conjunto com eles; 6. A verificao de consistncia necessria para conseguir buscar uma otimizao dos cenrios e restries g e r a d as . P r e v ainda que possamos minimizar o uso de estratgias de satisfao (tabela 4.3) que podem trazer conseqncias negativas para o projeto e verificar a dependncia entre RNF gerados.
4 .2 .3 F a se 3 De fini o de As pe c to s Ca ndida to s
Segundo Souza (2004), que se utiliza de casos de uso, o aspecto ou requisito aspectual possui as seguintes caractersticas: a) representa uma preocupao que deve ser inserida num caso de uso base, alterando o fluxo de execuo desse caso de uso, mas cujo propsito no est diretamente associado ao objetivo do caso de uso base; b) pode ser desvinculado do caso de uso base sem que isso impea a realizao do objetivo do caso de uso; c) ele (ou pode vir a ser) aplicado em vrios casos de uso e no apenas num caso de uso especfico.
Na implementao da ferramenta para validar a abordagem foi includo restries OCL na construo de cenrios.
103
Neste trabalho utilizado a tcnica de cenrios, logo, a identificao dos aspectos candidatos deve ser realizada aps a incluso dos cenrios no LEL, isto porque ir facilitar o processo de identificao. O processo de abstrair smbolos ou especificaes que possam representar uma preocupao que est atravessada no projeto, ou seja, um possvel aspecto candidato, pode ser identificado na abordagem atravs das seguintes diretrizes: D1) RNFs a identificao de requisitos no funcionais um forte candidato a ser um aspecto, pois como sabemos os RNFs so transversais por natureza (Yu et al 2004). Deste modo, todos os RNF sero mapeados como aspectos candidatos. D2) Um cenrio includo pode ser um aspecto candidato a partir das seguintes caractersticas: a) no est associado diretamente a um Ator; b) aparece como uma restrio ou extenso de um cenrio principal ou base (o que possui a funcionalidade principal); c) (ou pode vir a ser) aplicado em vrios cenrios base; e d) se o retirarmos no altera a funcionalidade do cenrio base. Este aspecto candidato ter alguns campos especiais: Tipo de contribuio - Esta contribuio pode ser negativa (quando ir influenciar negativamente para o entendimento e complexidade do cenrio base) ou positiva (ele contribui de forma a auxiliar na compreenso do cenrio), de acordo com a tabela 4.3. Tipo de Composio Esta composio segue o padro proposto por Souza (2004).
4.2.3.1 - Identificando Contribuies dos Aspectos Candidatos As contribuies dos aspectos candidatos em relao aos cenrios devem ser identificadas, ou seja, o quanto um aspecto ir restringir ou influenciar o cenrio. Esta contribuio poder definir se existem aspectos que no sero implementados, devido alta contribuio negativa em relao ao sistema. Esta deciso fator exclusivamente de gerncia de projeto e deve ser feita em conjunto com os usurios envolvidos.
104
De forma geral, quando restringe de forma negativa, deve-se levar em conta que estamos lidando com usurios e, estes, no gostam de perda de tempo em determinada tarefa, por exemplo. Assim, se temos um aspecto que demanda em determinado cenrio que este ir demorar um pouco mais para ser satisfeito, devemos tomar cuidados para avaliar a situao caso a caso. As contribuies podem ser determinadas atravs da tabela 4.6.
TABELA 4.6 CONTRIBUIES DOS ASPECTOS
Cenrio Cenrio 1 Cenrio 2 ... Cenrio N
Aspectos Candidatos Aspecto 1 Aspecto 2 ... Aspecto n X + X X + X - + + X
4.2.3.2 - Definindo a Composio dos Aspectos Candidatos Em linguagem mais simples a definio de composio realizada para identificar como ser a chamada para a execuo do aspecto. Para isso utilizaremos o modelo proposto por Souza (2004), com adaptaes para cenrios. Devem ser determinadas informaes a respeito da composio entre um
requisito aspectual e os cenrios 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 . COMPOSIO DOS ASPECTOS IDENTIFICADOS
ASPECTO CANDIDATO: # ID <NOME>
CENARIO
AFETADO
CONDIO
REGRA DE COMPOSIO
PONTO DE
JUNO
INFORMAES
ADICIONAIS INFORMAES RELATIVAS A COMPOSIO
# ID <NOME>
CONDIO DA EXTENSO
{overlap.after| overlap.before| override.wrap}
PASSO DO CENRIO
Para preencher a tabela 4.7 deve ser seguido o seguinte roteiro:
105
1) Para cada ponto que um requisito aspectual precisar afetar num cenrio, haver uma entrada na tabela de composio nvel 1 cujas colunas devem ser preenchidas da seguinte maneira: a . C ENARIO AFETADO: preencha com o nome do cenrio no qual o comportamento do aspecto candidato deve ser inserido. b. CONDIO (OPCIONAL): preencha essa coluna caso haja alguma condio que deve ser satisfeita para que o comportamento do aspecto candidato seja inserido no cenrio. c. REGRA DE COMPOSIO: preencha com algum dos seguintes operadores de composio (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 juno (ver descrio dos operadores no Captulo 2). A definio de qual operador utilizar deve ser feita em conjunto com os stakeholders (em conjunto com o engenheiro de requisitos). d. PONTO DE JUNO: preencha com o passo do cenrio no qual o comportamento do aspecto candidato deve ser aplicado. e. INFORMAES ADICIONAIS (OPCIONAL): preencha com alguma outra informao que deseje acrescentar sobre a composio do aspecto candidato.
4.2.3.3 - Identificando Conflitos Como estamos trabalhando com a tabela de composio utilizada por Souza (2004), a resoluo de conflitos segue o mesmo padro. Neste caso, os conflitos so identificados quando diferentes aspectos candidatos devem ser aplicados em um mesmo ponto de juno de um cenrio. Quando temos operadores de composio diferentes, a ordem de execuo dos aspectos deve seguir a ordem de precedncia dos seus respectivos operadores de composio. Entretanto, se dois ou mais aspectos devem ser aplicados num mesmo ponto de juno de um cenrio com o mesmo operador de composio, ento existe um conflito, e a ordem de precedncia deve ser decidida pelo analista e definida numa tabela de conflitos (Tabela 4.8).
106
Existir apenas uma tabela de conflitos para todo o sistema, na qual todos os cenrios so listados nas linhas e os requisitos aspectuais nas colunas. Caso exista um conflito de um requisito aspectual num passo de um cenrio, a ordem de precedncia desse aspecto em relao aos aspectos com que ele conflita deve ser especificada na clula de interseo entre o cenrio e o aspecto da seguinte forma: P[numPassoConfl][siglaOperador]=[ordemPreced], onde: numPassoConfl deve ser substitudo pelo nmero do passo do cenrio onde existe o conflito; siglaOperador deve ser substitudo 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 substitudo pela ordem de precedncia do aspecto candidato. Vamos supor que, alm do aspecto candidato A C#01- Verificao de dbito, um outro aspecto candidato cujo identificador AC#03 precisasse ser aplicado no passo 3 do cenrio CN#05 - Fazer matrcula em disciplina com o operador wrap; e que a prioridade de execuo fosse concedida para o aspecto AC#03. Ento, 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 CN#1 CN#2 CN#3 CN#4 CN#5 AC#2 AC#3 AC#4
P3-W =2
P3-W=1
medida que os pontos de juno vo sendo refinados nos fluxos seguintes, esses conflitos podem deixar de existir. Contudo, essas prioridades definidas na tabela de conflitos sero teis no somente caso o conflito persista nos fluxos de anlise e projeto, mas tambm para auxiliar na definio dos pontos de juno nesses fluxos.
107
4 .2 .4 F a se 4 Ma pe a me nto de O nto lo g ia s
Segundo Gruber (2006) ontologias so especificaes formais e explicitas de conceitualizaes compartilhadas, ou seja, so modelos conceituais que capturam e explicitam o vocabulrio nas aplicaes semnticas. Breitman (2005) destaca que ontologias servem como base para garantir uma comunicao livre de ambigidades. O consorcio W3C (2006) define uma ontologia como: a definio dos termos utilizados na descrio e na representao de uma rea do conhecimento. Devem prover descries 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 construo do lxico existente na DAORE.
TABELA 4.9 . MAPEAMENTO DOS ELEMENTOS DO LEL PARA OS ELEMENTOS DA ONTOLOGIA. FONTE: BREITMAN&LEITE (2003).
Elementos do LEL Objeto e Sujeito Estado Verbo Noo Impacto verbo Impacto predicado(termos)
Elementos da Ontologia Classes Classe ou propriedade Propriedade Descrio Propriedade Classes ou axiomas
No mapeamento descrito na tabela 4.9 podemos observar que os elementos ou termos classificados como do tipo objeto e sujeito so mapeados em classes da ontologia; os elementos classificados como do tipo verbo so mapeados para propriedades. O s termos classificados como do tipo estado para classes o u propriedades, dependendo de sua importncia relativa para a ontologia; a noo de cada termo mapeada na descrio da respectiva classe; e atravs da lista de impactos de cada termo do lxico mapeia-se o verbo em propriedades e o predicado em restries (axiomas) das classes. Breitman (2005) argumenta ainda que este processo de mapeamento independente da linguagem de implementao da ontologia, como , por exemplo a OWL 4 , entre outras.
Disponvel em http://www.co-ode.org/resources/tutorials/protegeowltutorial.pdf
108
Nossa proposta realiza a converso de acordo com a tabela 4.9. No captulo 5 veremos na prtica como ir funcionar. O processo de mapeamento de ontologias inclui tambm a construo da hierarquia de classes e consiste na anlise da ontologia de modo a identificar conceitos que possam estar relacionados hierarquicamente. Breitman (2005) argumenta que as classes de uma ontologia se relacionam, estruturalmente, atravs do relacionamento de especializao, ou seja, no topo da ontologia fica o elemento mais genrico, e nas suas folhas os mais especficos. Para facilitar o entendimento vamos expor o exemplo apresentado por Breitman (2005), onde apresenta termos referentes a um domnio de sobremesas. A construo 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 Torta
Pudim
Mousse
Classes relacionadas Torta de coco Petit- gateau Torta de limo Pudim de chocolate Pudim de laranja Manjar de coco Mousse de maracuj Mousse de cupuau Mousse de limo
A tabela 4.8 apresenta a classe pai criada para conter as classes filho relacionadas.
4 .2 .5 Ge ra o de a rquiv o s pa ra Ex po rta o
Apesar de no estar no modelo de processo proposto (figura 4.1) a exportao do modelo LEL, ontologias e aspectos atravs de um documento XML so muito importantes a fim de permitir uma interoperabilidade entre ferramentas. O trabalho de Wiese (2006) aborda a questo de interoperabilidade entre as ferramentas de desenvolvimento, realizando um trabalho de transformao entre modelos de casos de uso, entre as ferramentas: Poseidon5 , Enterprise Architect6 e a Requisite.
5
Disponvel para download em: http://www.gentleware.com/.
109
Porm, este trabalho no lida com casos de uso, mas sim do LEL, aspectos e ontologias. Deste modo, a definio de padres de documentos XML Schema importante no sentido de que eles servem para validar arquivos XML e permitirem uma organizao da nomenclatura a ser utilizada. Os documentos XML Schema foram gerados atravs da ferramenta Stylus Studio 6 XML Enterprise Edition7 e so organizados como se segue: 1) Padronizando os termos usados nos smbolos do LEL
LELSimbolos.xsd
2) Padronizando os termos usados nos cenrios do LEL;

LELCenario.xsd
3) Padronizando os termos usados nos elementos da ontologia;

ontologia.xsd
4) Padronizando os termos com as classes pai e seus filhos da ontologia

ontohierarquia.xsd
5) Padronizando os termos usados nos aspectos candidatos;

AspectosLEL.xsd
Os arquivos XML Schemas propostos esto na ntegra no anexo A.
4 .3 Co ns ide ra e s so bre a a bo rda g e m DA OR E

Sero apresentadas algumas consideraes sobre a abordagem DAORE, proposta neste captulo, em relao aos objetivos propostos e abordagens estudadas no captulo 2.
4 .3 .1 Co m Re la o a o s Obje t iv o s P ro po sto s
A tabela 4.11 apresenta as consideraes da abordagem DAORE com relao aos objetivos propostos.
6 7
Disponvel para download em: http://www.sparxsystems.com/ Esta ferramenta se encontra disponvel para download em: www.stylusstudio.com/.
110
A coluna Objetivo Proposto apresenta o que se deseja, a coluna abordagem DAORE apresenta como foi realizada na abordagem e a coluna consideraes apresenta observaes julgadas pertinentes.
TABELA 4.11 DAORE E OS OBJETIVOS PROPOSTOS
Objetivo Proposto Utilizar o LEL e permitir a identificao de propriedades transversais do projeto Suporte a metodologia MDSODI na definio dos cenrios e das propriedades transversais Permitir um alto grau de usabilidade
Abordagem DAORE Atravs de diretrizes para este fim.
Atravs da definio do tipo do cenrio especificado.
Boa adequao quanto identificao de propriedades transversais Identificar requisitos organizacionais, atravs de suas operacionalizaes Especificar XML Schemas para auxiliar na exportao de documentos padro no formato XML Facilitar a resoluo de conflitos Facilitar o rastreamento de requisitos
Permite uma rpida compreenso e entendimento do mtodo, uma vez que utiliza de conceitos j existentes (LEL) A identificao de propriedades transversais feita de forma semiautomtica Atravs da incluso de restries nos cenrios. Foi criado XML Schemas para este fim
Consideraes As propriedades transversais so obtidos aps a especificao dos cenrios. Para o ator envolvido no cenrio, seu tipo ser definido de acordo com o mesmo. A forma de elaborao do LEL no foi alterada. Apenas acrescentou-se novas caractersticas (restries) Atravs das diretrizes propostas
Atravs de padro existente definido por Souza (2004) Atravs do principio do LEL de circularidade e vocabulrio mnimo.
Utilizou-se de smbolos do LEL, cenrios, aspectos e ontologias, tanto dos termos quanto da hierarquia de classes. Pode ser gerado automaticamente. Este princpio no foi alterado.
4 .3 .2 Uso na Re quis ite e no P ro je to D iSEN

No captulo 6 ser apresentado em detalhes as mudanas a realizadas (e as que podem ser realizadas) na ferramenta Requisite a fim de prover as caractersticas determinadas na DAORE, bem como no projeto DiSEN.
111
4 .3 .3 D ife re n a s c o m a s A bo rda g e ns Est uda da s

Por definir os cenrios atravs do LEL, a abordagem DAORE j nica em sua concepo, uma vez que no foi encontrada uma abordagem que se utiliza do LEL e aspectos. Por outro lado, a DAORE conseguiu buscar algumas caractersticas das abordagens estudadas que facilitam o seu entendimento (como pode ser verificado na tabela 4.1). A abordagem DAORE em seu objetivo bsico facilitar a identificao das propriedades transversais consegue minimizar o problema de identificao comum n a maioria das abordagens. Assim, seu diferencial principal est em aliar a praticidade e a maturidade do LEL nos projetos com a identificao das propriedades transversais a partir deste LEL. Aliado a isso, podemos incluir o tipo de cenrio utilizado a partir da metodologia MDSODI, o que a torna integrada a metodologia.
Neste captulo foram apresentadas as diretrizes para a abordagem DAORE, o que ela prope 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 Captulo 3 com algumas adaptaes e inseres novas (como a utilizao de padres de qualidade para a definio dos requisitos no funcionais e a identificao e integrao dos requisitos organizacionais na modelagem). Outro aspecto importante da DAORE o de permitir a portabilidade e interoperabilidade entre plataformas e ferramentas, atravs do padro 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 captulo procuramos dar uma ateno especial na elicitao dos requisitos e como identificar os aspectos (uma preocupao constante em todas as abordagens estudadas) utilizando nossa abordagem, de forma semi-automtica. Assim, procuramos minimizar um dos principais problemas existentes na separao de propriedades: a sua efetiva identificao.
112
No prximo captulo faremos a experimentao da abordagem e ser realizado uma anlise do impacto das mudanas a serem efetuadas na ferramenta Requisite, apresentadas no captulo 6.
5.Experimentao: Controle de Eventos Cientficos
113
CAPTULO
5
EXPERIMENTAO: CONTROLE DE EVENTOS CIENTFICOS
As palavras que no so seguidas de fatos no servem para nada. Demstenes
Segundo TRAVASSOS et a l ( 2002) e xis tem duas tc nic as para ava liar uma abordagem: e xper ime ntos e es tudos de c as o. A rea liz a o de exper imentos prov uma mane ira de ava lia o bas eada em c ompara o direta, permit indo aos pes quis adores inves t iga r qua l o impac to da tec nologia no proc ess o de mane ira detalhada. O es tudo de c asos es t preoc upado em ava liar os benef c ios de uma abordagem para ver if ic ar s e as mudan as no proc esso proporc ionaram o res ult ado esperado. A tc nic a es c olhida para es te t raba lho foi o de exper imenta o. Aplic are mos a abordagem DAORE em um s is tema de s oftware fic t c io de uma e mpres a que re a liz a e ventos c ie nt fic os , o mes mo apres entado por Batis ta (2003), porm com o ac rsc imo de outras c arac ter s tic as. Inic ia lmente apres entar emos o s is tema propos to, s eus requis itos func iona is , no func iona is e organizac iona is . A partir des ta baseline
114
des envolver emos noss o projeto a f im de c ompararmos c om o anter ior (re a liz ado no c apitulo 6).
5 .1 O bje t iv o s
Este estudo de caso tem o propsito de: (i) mostrar como a DAORE pode ser usada para melhorar o entendimento e identificao 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 validao da ferramenta Requisite, escolhemos o mesmo para facilitar o processo de comparao e anlise do impacto do uso da abordagem DAORE para o processo de desenvolvimento. A seguir descreveremos o contexto do sistema proposto para realizar nossa avaliao final.
5 .2 A Esc o lha da F e rra me nta de Im ple me nta o

A escolha da ferramenta OORNF para apoiar a abordagem proposta se deve a algumas consideraes: a) A ferramenta Requisite estava sendo analisada e alterada por Wiese (2006) para seu projeto, de modo que somente aps o trmino deste trabalho poderia ser analisado o quanto foi alterada, pois inicialmente nem mesmo possua persistncia em seus dados e identificao de seus termos (elementos do LEL); b) Foram feitas algumas anlises 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 persistncia, identificao dos smbolos do LEL e possui integrado os requisitos no funcionais na definio do LEL, f o i desenvolvida em Delphi.
(CYSNEIROS, 2002) desenvolvida no trabalho do prof. Cysneiros da Universidade de York, TorontoCanad, que disponibilizou o cdigo fonte. 2 Disponvel no site http://139.82.24.189/cel/, onde possui inclusive o cdigo fonte.
115
b.2) A ferramenta C&L possui persistncia, identificao dos smbolos do LEL e possui integrado a construo de ontologias do LEL, foi desenvolvida em PHP. c) O objetivo principal da DAORE o de facilitar a identificao de aspectos candidatos, onde podemos primeiramente salientar os derivados dos requisitos no funcionais. Baseado, principalmente no item C, foi escolhida a ferramenta OORNF para a alterao, por j ter integrado os requisitos no funcionais, mesmo que fosse feita alterao na forma da integrao, pois facilitaria a identificao dos aspectos candidatos. A nova verso da OORNF passou a chamar-se CALEL Candidates Aspects from LEL, aprovado pelo prof. Cysneiros. Alterada no sentido de prover recursos para a incluso de ontologias, requisitos organizacionais e a exportao nos padres especificados no Captulo 4, suas telas esto no anexo B. Porm, a alterao prevista da ferramenta Requisite est descrita em detalhes no Captulo 6. O uso da CALEL foi apenas para fins de estudo de caso.
5 .3 O Siste ma P ro po sto
Uma empresa presta servios de gerenciamento de eventos. O cliente ou tambm chamado de cliente em potencial pode consultar os eventos que esto 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 inscrio para os eventos que iro ocorrer. Seu cadastro ser analisado e caso seja aprovado (depende de consulta do CPF e rgos compententes), poder inscrever-se como ouvinte, para assistir as palestras, apresentaes e cursos do evento ou poder enviar trabalhos (short paper, long paper ou pster), sendo a aceitao do trabalho condicionada avaliao por comit cientifico. Em qualquer dos dois casos (ouvinte ou participante) dever pagar a inscrio. Os clientes cadastrados tambm podem participar do evento como palestrante ou ministrante. O palestrante convidado pela comisso organizadora para realizar uma ou mais palestras durante o evento. O ministrante convidado pela comisso organizadora para ministrar um ou mais cursos durante o evento. Nestes casos o participante estar isento da taxa de inscrio.
116
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 requisio de recursos necessrios para a sua execuo nos prazos estabelecidos. A comisso organizadora elaborar a programao do evento com base nos trabalhos, cursos e palestras. A comisso tambm responsvel por cadastrar os parceiros do evento (fornecedores, patrocinadores). Os recursos financeiros so providos pelos patrocinadores e iro servir para pagar os fornecedores do evento (de recursos materiais e humanos). A secretaria responsvel por distribuir os recursos financeiros recebidos. Mesmo os clientes j cadastrados devem se preocupar em verificar sua situao junto aos rgos competentes quando da sua inscrio para um novo evento. Caso sua situao no esteja em ordem sua inscrio dever ocorrer apenas se o pagamento for em dbito em conta. No sero convidados (palestrantes e ministrantes) pessoas com problemas com os rgos competentes. Crachs de identificao devem ser entregues a todos os participantes do evento. S ser permitido o acesso ao evento aos portadores de crachs. Para comprovar a participao no evento, os participantes recebero certificados de participao. Os certificados s devero ser emitidos para os participantes com, no mnimo 85% de presena. A empresa deseja conseguir o maior nmero de clientes VIP. Um cliente VIP aquele que solicita mais de trs eventos anuais. A este cliente concedido um desconto especial de 30% nos servios prestados. Para os participantes que so freqentes (mais de trs eventos anuais) tambm oferecido descontos especiais em hotis, restaurantes e outros patrocinadores, possuindo um carto de Cliente VIP da empresa.
5 .4 F a se 1 - Ide nt if ic a ndo o s Re quis ito s

Seguindo o modelo proposto por Toranzo (2002) e j colocando os requisitos de acordo com as regras estabelecidas para o LEL, construmos a tabela 5.1 e 5.2.

TABELA 5.1 REQUISITOS DO SISTEMA
117
Re quis itos func io nais Secretr ia cada stra c lie nte Part ic ipa nte co ns ulta e ve nto s e m abe rto Part ic ipa nte co ns ulta e ve nto s fec hado s Secretr ia co ns ulta e ve ntos e m aber to Secretr ia cada stra o uvinte e m um e ve nto e m aber to Ouvint e se cadas tra e m um e ve nto e m aber to Part ic ipa nte se cadas tra e m um e ve nto e m aberto Part ic ipa nte e nvia traba lhos Secretr ia o u a co mis so a lte ra o p art ic ipa nte e m um e ve nto e m abe rto co m no mni mo 24 hora s de a nte ced nc ia Secretr ia o u o co mit exc lue m o par t ic ipa nte e m um e ve nto e m aber to co m no mnimo 7 dias te is de a nteced nc ia Secretr ia co ns ulta pa rt ic ipa ntes e m um e ve nto Secretr ia cada stra e ve nto Secretr ia cada stra co misso or ga nizador a do e ve nto Secretr ia cada stra co mit c ie nt fico do e ve nto Comit c ie nt fic o se le c io na traba lhos Comisso or ga nizado ra cadas tra pro gra ma o do e ve nto Comisso co nfecc io na crac hs do e ve nto Part ic ipa nte recebe c rac h Comisso e labora cer t ificados de par t ic ipao pa ra os p art ic ipa ntes co m, no mn imo, 85% de prese na Comisso cada str a minis tra nt e Comisso cada str a pa les tra nte M inis tra nte apre se nta c ursos aprese ntado r apre se nta traba lhos Palest ra nte ap rese nta pa le stra Part ic ipa nte recebe ce rt ific ados de par t ic ipao Comisso cada str a patro c inador es do e ve nto Ouvint e e/o u ap rese nt ador e fe t ua pa ga me nto do e ve nto
TABELA 5.2 REQUISITOS NO FUNCIONAIS E ORGANIZACIONAIS DO SISTEMA
Re quis itos no f unc io nais Segura na Acesso loca l Atra vs de se nha e fir ewa ll Acesso inte r net Re quis itos orga ni zacio na is Faci li ta r o ace ss o de e ve ntos a clie nte s Gere nc iar c lie ntes VIP VI P Emit ir car to pre fere nc ia l O part ic ip a nte ao s e cadas trar e m um e ve nto o s iste ma ver se e le um c lie nte VIP o u se te m pot e nc ia l para s er um c lie nte VIP Para os no vos c lie nt es VIP ser e mit ido um car to pre fere nc ia l Nem sempre observamos os requisitos no funcionais e muitas vezes eles no esto explcitos. A tabela 4.3 apresentada no Capitulo 4 pode servir de base para que
118
possamos incluir os requisitos no funcionais de uma forma mais natural, uma vez que grande parte dos requisitos no funcionais j esto listados. Veremos mais adiante que nossos requisitos no funcionais e organizacionais sero includos de maneira distintas dos requisitos funcionais. No Anexo E demonstramos a incluso do Lxico atravs da ferramenta CALEL, cuja Figura 5.1 demonstra a tela:
FIGURA 5.1 MENU PRINCIPAL DA FERRAMENTA CALEL.
5 .4 F a se 2 - Co nst ruindo o l x ic o
Para a construo do lxico iremos, primeiramente incluir os requisitos funcionais do sistema. A Figura 5.2 apresenta a tela de incluso do lxico.
119
FIGURA 5.2 TELA DE INCLUSO DO LEL
Para a construo do lxico, primeiramente inclumos os requisitos funcionais do sistema. A Figura 5.2 apresenta a tela de incluso do lxico. Os smbolos apresentados na Tabela 5.3 foram identificados nos requisitos funcionais para a incluso no LEL.
TABELA 5.3 S MBOLOS DO LEL ENCONTRADOS NOS REQUISITOS FUNCIONAIS
tipo Sujeito
Estado Objeto
Verbo
Descrio Secretria/Auxiliar, Participante, ouvinte, ministrante, palestrante, apresentador, fornecedor/patrocinador/parceiro, c o m i s s o organizadora/comisso, comit cientfico/comit, cliente inscrito/cliente cadastrado, cliente/cliente em potencial Em aberto/aberto/abertos, fechado/fechados Evento, trabalhos/trabalho, programao/programa, crach/crachs, certificado/certificados/certificado de participao, pagamento, recursos/recurso, material de aula, slides/palestra, inscrio Incluir cliente/cadastrar cliente/cliente cadastrado, consultar eventos em aberto, consultar eventos fechados, alterar participante, excluir participante, consultar participante, cadastrar comisso, cadastrar comit, receber recursos, distribuir recursos, pagar fornecedor, efetuar inscrio, efetuar pagamento, enviar material, enviar requisio, enviar trabalho, enviar palestra, fornecer recursos, receber pagamento, s elecionar ministrante, selecionar palestrante, emitir crachs, emitir certificados, elaborar programao, cadastrar parceiros, solicitar inscrio
120
A tabela 5.4 possui em detalhes as entradas do LEL correspondente aos smbolos encontrados na tabela 5.3, vale observar que o termo sublinhado indica que faz parte do prprio lxico.
TABELA 5.4 S MBOLOS DO LEL DETALHADO
S mbolo Noo I mpa cto
Re quis itos func io nais Secretar ia/ Auxilia r Cate goria Pessoa q ue a uxilia no ge re nc ia me nto do e ve nto Aes q ue e xec uta : 1. cadastra r c lie nte, 2. cons ulta r e ve nto s e m abe rto 3. cons ulta r e ve nto s fec hados 4. a lter ar par t ic ipa nte 5. exc luir p art ic ipa nte 6. cons ulta r par t ic ipa ntes 7. cadastra r e ve nto 8. cadastra r co misso 9. cadastra r co mit 10. receber r ec ursos 11. paga r for nec edor 12. distr ib uir rec ursos 13. receber pa ga me nto
Suje ito
Part ic ipa nte Cate goria Suje ito Pessoa q ue par t ic ipa de um e ve nto co mo : o uvinte, apr ese ntado r, pa le str a nte, minis tra nte Aes q ue e xec uta : 1. cons ulta r e ve nto s e m abe rto 2. cons ulta r e ve nto s fec hados 3. cons ulta r pro gra mao ouvinte Cate goria Suje ito Cliente inscrito para assistir aos cursos, palestras e apresentaes do evento Aes q ue e xec uta : 1. efet uar p a ga me nto Clie nte inscr ito /c lie nte c adast rado Cate goria Suje ito Pessoa q ue so lic ito u o cadas tro e fo i ap ro vada, recebe ndo o se u lo gin e se nha Aes q ue e xec uta : 1. inscre ve- se e m e ve ntos 2. cons ulta r e ve nto s aber tos 3. cons ulta r e ve nto s fec hados 4. cons ulta r pro gra mao 5. enviar t raba lho s 6. efet uar p a ga me nto Palest ra nte Cate goria Suje ito Cliente inscrito para ministrar palestra Aes q ue e xec uta :
S mbolo Noo I mpa cto S mbolo Noo I mpa cto
5.Experimentao: Controle de Eventos Cientficos 1. enviar pa lest ra M inis tra nte Cliente inscrito para ministrar curso Aes q ue e xec uta : 1. enviar mater ia l 2. enviar req uis io Aprese ntador Cliente inscrito para apresentar trabalho Aes q ue e xec uta : 1. enviar t raba lho
121
Cate goria
Suje ito
Cate goria
Suje ito
S mbolo Noo I mpa cto S mbolo Noo
I mpa cto
Comisso /co misso o r ga nizado ra Cate goria Suje ito Gr upo de pes soas se lec io nad as para ge re nc iar o e ve nto. Aes q ue e xec uta : 1. Selec io na r minis tra nt e, 2. Selec io na r pa les tra nte, 3. Emit ir cra c hs, 4. Emit ir cer t ificado s 5. Cons ultar pa rt ic ipa ntes 6. Elabo rar pro gra ma o 7. Cadastrar pa rce iros Comit /co mit c ie nt fic o Cate goria Suje ito Gr upo de pessoas se lec io nada s para se lec io na r os traba lhos ap rese ntados no eve nto. Aes q ue e xec uta : 1. Selec io na r trab a lhos 2. Alt erar pa rt ic ipa nte Parce iro s/Parc e iro /For necedo r/Pa troc inador Cate goria Suje ito Emp resas q ue for nece m rec ursos ( mat er ia is, fina nce iros o u huma nos) p ara a rea lizao do e ve nto Aes q ue e xec uta : 1. Fornec er rec ursos 2. cons ulta r e ve nto s 3. cons ulta r pro gra mao Fornec edor Cate goria Suje ito Emp resas q ue fo r nece m re c ursos mate r ia is e/o u huma no s para a rea lizao do eve nto Aes q ue e xec uta : 1. receber pa ga me nto_ rec urso Eve nto /e ve nto s Cate goria Objeto Confer e nc ia o u Work s hop a ser ger e nc iado pe la e mp resa. Cada e ve nto pos s ui um p er odo de rea lizao. co mpo sto de uma o u ma is pa lest ras, c ur sos e t raba lho s 1. Clie nte inscr ito pode inscr e ver- se e m e ve nto 2. O eve nto e st abe rto o u fec hado Traba lhos/ traba lho Cate goria Art igos a se re m ap rese ntados e m um e ve nto Objeto
S mbolo Noo
122
I mpa cto S mbolo Noo I mpa cto S mbolo Noo I mpa cto
Pode ser : s ho rt pape r, full paper e poste r 1. Aprese ntador e nvia um o u ma is trab a lhos 2. O traba lho pode se r se lec io nado pa ra se r aprese ntado por um co mit Progra mao /pro gra ma Cate goria Objeto Crono gra ma a se r c ump r ido do e ve nto Conte m as pa lest ras, t raba lho s e c urso s a ser e m apr ese ntad os no e ve nto 1. Comisso e labora p ro gra mao pre vista do e ve nto 2. A pro gra mao pode s er a lterad a caso ocor ra a lgum impre visto Cert ificado/ cert if icado par t ic ipao Cate goria Objeto Compro va nte de pa rt ic ipao do e ve nto 1. Comisso e labora ce rt ific ados para o s par t ic ipa ntes 2. Cert ificados s ero e ntre gues no ult imo d ia do e ve nto o u via cor re io Crach s/cr ac h Cate goria Objeto Ident ifica o do part ic ip a nte do e ve nto 1. Comisso e mit e crac h s para os p art ic ipa ntes 2. Crach s sero e ntre gue s no pr ime iro d ia do e ve nto 3. Crach s so rec eb idos pe los par t ic ipa nt es Paga me nto Cate goria Objeto Comprovante de quitao com o evento 1. Ouvinte/pa les tra nt e e nt re ga cop ia do pa ga me nto e fet uado via e- ma il, corre io, o u no p r ime iro d ia do e ve nto Rec urso s/r ec urso Cate goria Objeto So materiais necessrios para a realizao e elaborao do evento. Podem ser: financeiro, humano e material Os rec urso s fina nce iros so d ispo nib il izados a ntes dos rec urso s mater ia is e huma nos Mater ia l/ ma ter ia is Cate goria Objeto O ma ter ia l re fere nte ao c ur so a ser min ist rado e m um e ve nto 1. M inis tra nte e nvia um o u ma is mate r ia is 2. O ma ter ia l pode se r se lec io nado po r um co mit Palest ra Cate goria Objeto Slides referentes a um assunto a ser apresentado no evento 1. Palest ra nte e nvia uma o u ma is pa le stra s 2. A pa les tra pode ser se lec io nada por um co mit Req uis io Cate goria Objeto Documento que contem referencias aos recursos materiais necessrios para realizar a tarefa 1. M inis tra nte e nvia ape nas uma req uis io Cadastrar c lie nte Cate goria Verbo Ao rea lizad a pe la s ecre tr ia Aco ntece q ua ndo : a pes soa so lic ita se u c adast ro co mo c lie nte inscr ito Pr- cond : 1. Pessoa int eress ada e nvia se us dados cad ast ra is 2. Secretr ia re cebe os dados e rea liza a n lis e. Infor maes so ap ro vadas 1. Clie nte e st cada str ado 2. Se o c lie nte est cadas trado a se cret r ia no pode cadas tr- lo.
S mbolo Noo I mpa cto S mbolo Noo I mpa cto S mbolo Noo I mpa cto S mbolo Noo I mpa cto S mbolo Noo I mpa cto S mbolo Noo
I mpa cto
123
S mbolo Noo
I mpa cto S mbolo Noo
I mpa cto
S mbolo Noo
I mpa cto S mbolo Noo I mpa cto S mbolo Noo
Ps- cond : 1. Secretr ia e nvia lo gin e se nha pa ra o c lie nte inscr ito. Cons ultar e ve nto s e m abe rto / e ve ntos e m Cate goria Verbo aberto so co ns ultados Ao rea lizada pe la sec ret r ia, par t ic ipa nte, parce iros, c lie ntes cadast rados, c lie ntes Aco ntece q ua ndo : a pesso a/e mpresa dese ja saber q ua is os eve ntos esto a acontecer 1. Eve nto s fora m co ns ultados. Ps- cond : Cons ultar e ve ntos fec hados/ e ve ntos Cate goria Verbo fe c hados so co ns ult ados Ao rea lizada pe la sec ret r ia, par t ic ipa nte, parce iros, c lie ntes cadast rados, c lie ntes Aco ntece q ua ndo : a pessoa /e mp resa d eseja sabe r q ua is os e ve ntos acontecera m 1. Eve nto s fora m co ns ultados. Alt erar pa rt ic ipa nte/ pa rt ic ipa nte a lterado Cate goria Verbo Ao rea lizad a pe la s ecre tr ia, co mit Aco ntece q ua ndo : o par t ic ipa nt e de o uvinte passa a ser um aprese ntador Pr- cond : 1. Part ic ipa nte est c adast rado no e ve nto co mo o uvinte 2. Comit se lec io na tr aba lho do o uvinte 1. part ic ipa nt e est a lt erado. Exc luir pa rt ic ipa nte/pa rt ic ipa nte e xc luido Cate goria Verbo Ao rea lizad a pe la s ecre tr ia Aco ntece q ua ndo : o par t ic ipa nt e no pode es tar no e ve nto Pr- cond : 1. Part ic ipa nte info r ma a s ecre tr ia s ua pro v ve l a us nc ia 1. Part ic ipa nte est e xc ludo. Ps- cond : 1. Se o part ic ipa nt e for um o uvinte o u apres e ntador e o pra zo da e xc luso fo r ma ior q ue 5 d ias te is, o va lor de vo lvido se r de 80% 2. Com e xce o do par t ic ipa nte s er um o uvinte, ser e nviado e- ma il para os ouvintes sobre a a lte rao e fet uada. Cons ultar par t ic ipa ntes / pa rt ic ipa nte Cate goria Verbo cons ultado Ao rea lizad a pe la s ecre tr ia, co misso Aco ntece q ua ndo : dese ja- se co nhece r os part ic ip a ntes de um e ve nto e m abe rto ou fe c hado 1. Part ic ipa nte s fora m co ns ultados . Ps- cond : Cadastrar e ve nto/ e ve nto cada str ado Cate goria Verbo Ao rea lizad a pe la s ecre tr ia Aco ntece q ua ndo : a e mpresa recebe um e ve nto pa ra gere nc iar 1. Eve nto e st cad ast rado. Cadastrar co mis so/co mis so cadas trada Cate goria Verbo Ao rea lizad a pe la s ecre tr ia Aco ntece q ua ndo : o e ve nto no poss ui co misso
5.Experimentao: Controle de Eventos Cientficos I mpa cto S mbolo Noo I mpa cto S mbolo Noo
124
I mpa cto
S mbolo Noo
1. Comisso es t cada strad a. Cadastrar co mit /co mit cadas trado Cate goria Verbo Ao rea lizad a pe la s ecre tr ia Aco ntece q ua ndo : o e ve nto no poss ui co mit o r ga nizado r 1. Comit es t cada strado. Ps- cond : Receber rec ur sos/ rec urso s receb idos Cate goria Verbo Ao so fr ida pe la sec ret r ia Aco ntece q ua ndo : o e ve nto no poss ui rec ursos Pr- cond : 1. Parce iro s for nec e m re c ursos 1. Rec urso s fora m rec eb idos. Ps- cond : Dis tr ib uir rec urso s/re c ursos d is tr ib uidos Cate goria Verbo Ao rea lizad a pe la s ecre tr ia Aco ntece q ua ndo : o e ve nto no poss ui rec ursos Pr- cond : 1. Rec urso s fora m rec eb idos 2. Eve nto po ss uir necess idade de r ec ursos 1. Rec urso s fora m rec eb idos. Pagar for necedo r/ for necedo res pa gos Cate goria Verbo Ao rea lizad a pe la s ecre tr ia Aco ntece q ua ndo : o e ve nto poss ui rec ur sos para pa ga me nto de fo r necedor Pr- cond : 1. fo r necedor for nece u rec urso s 2. fo r necedor no fo i pa go 1. Fornec edor fo i pa go. Ps- cond : 1. Fornec edor rec ebe pa ga me nto_rec urso Receber p a ga me nto/pa ga me nto receb ido Cate goria Verbo Ao so fr ida pe la sec ret r ia Aco ntece q ua ndo : a secre tr ia recebe u o pa ga me nto do o uvinte e/o u aprese ntado r Pr- cond : 1. Ouvint e e/o u ap rese nt ador es to ins cr itos no e ve nto 2. Ouvint e e/o u ap rese nt ador e fe t uo u pa ga me nto 1. Paga me nto fo i rec eb ido. Cons ultar pro gr a mao / pro gra mao Cate goria Verbo cons ultada Ao rea lizad a pe los pa rt ic ipa ntes, pa rce iros, c lie nte s insc r itos, c lie nt es Aco ntece q ua ndo : dese ja- se co nhecer a pro gra mao de um e ve nto Pr- cond : 1. Eve nto s e m abe rto so co ns ultados 2. Eve nto se lec io nado 1. Progra mao co ns ultada. Inscre ve r- se e m e ve nto / inscr io e fe t uada Cate goria Verbo Ao rea lizad a pe lo c lie nte ins cr ito Aco ntece q ua ndo : dese ja- se insc re ver- se par a um e ve nto e m abe rto Pr- cond :
125
I mpa cto
S mbolo Noo
3. Eve nto s e m abe rto so co ns ultados 4. Eve nto se lec io nado 1. Inscr io e fe t uada. Envia r tr aba lho /trab a lho e nviado Cate goria Verbo Ao rea lizad a pe lo ap rese nt ador Aco ntece q ua ndo : o c lie nte ins cr ito desej a enviar um traba lho para aprese nta o Pr- cond : 1. Clie nte inscr ito est cadas trado no e ve nto e m aber to co mo aprese ntado r Prazo d e s ub misso de traba lhos es t va le ndo 1. traba lho e nviado. Ps- cond : Efe t uar pa ga me nto / pa ga me nto e fet uado Cate goria Verbo Ao rea lizad a pe lo o uvinte e /o u apres e ntador Aco ntece q ua ndo : o o uvinte e /o u apre se ntado r poss ui pa ga me nto a fa zer do eve nto Pr- cond : 1. ouvinte e /o u aprese ntador e sto inscr ito s no e ve nto 1. paga me nto e fet uado. Ps- cond : 1. Paga me nto receb ido pe la sec reta r ia Envia r pa le stra / pa lest ra e nviada Cate goria Verbo Ao rea lizad a pe lo pa lest ra nte Aco ntece q ua ndo : o pa lest ra nte de seja e nviar a p a les tra pa ra o e ve nto Pr- cond : 1. Clie nte inscr ito e st cada str ado no e ve nto e m aber to co mo p a les tra nte 2. Prazo d e e nvio das p a les tras est va le ndo 1. pa lest ra e nviada. Ps- cond : Envia r ma ter ia l/ ma ter ia l e nviado Cate goria Verbo Ao rea lizad a pe lo minis tr a nte Aco ntece q ua ndo : o minis tra nte dese ja e nvia r o ma ter ia l do c ur so para o eve nto Pr- cond : 1. Clie nte inscr ito e st cada str ado no e ve nto e m aber to co mo min ist ra nte 2. Prazo d e e nvio do mate r ia l est va le ndo 1. mater ia l e nviado. Envia r req uis io / req uis io e nviada Cate goria Verbo Ao rea lizad a pe lo minis tr a nte Aco ntece q ua ndo : o minis tra nte dese ja e nviar a req uis io do mater ia l do cur so para o e ve nto Pr- cond : 1. Clie nte inscr ito e st cada str ado no e ve nto e m aber to co mo min ist ra nte 2. Prazo d e e nvio do mate r ia l est va le ndo 1. requis io e nviada. Selec io na r minis tra nte/ minis tra nte Cate goria Verbo se lec io nado Ao rea lizad a pe lo co mis so
126
I mpa cto
S mbolo Noo
I mpa cto
S mbolo Noo I mpa cto S mbolo
Noo
Aco ntece q ua ndo : o co misso de seja s e lec io nar o( s) minis tra nte(e ) para o eve nto Pr- cond : Eve nto po ss ui va ga s nos hor r ios d e pro gra mao 1. minis tra nte se lec io nado. Ps- cond : 1. e nviado e- ma il pa ra o minis tra nte co m o co nvite do e ve nto co nte ndo : ass unto de inter esse do c urso, pra zo e st imado pa ra o e nvio do mate r ia l e requis io e infor maes ger a is sob re o e ve nto. Selec io na r pa le stra nte/ pa les tra nte Cate goria Verbo se lec io nado Ao rea lizad a pe lo co mis so Aco ntece q ua ndo : o co misso desej a se lec io na r o(s ) pa lest ra nte (e) pa ra o eve nto Pr- cond : 1. Eve nto po ss ui va ga s nos hor r ios d e pro gra mao 1. pa lest ra nte se lec io nado. Ps- cond : 1. e nviado e- ma il pa ra o pa lest ra nte co m o co nvite do e ve nto co nte ndo : ass unto de inter esse da pa les tra, pra zo est imado pa ra o e nvio dos s lides e infor maes ge ra is sobre o e ve nto. Emit ir cra c hs/ c rac hs e mit idos Cate goria Verbo Ao rea lizad a pe la co mis so Aco ntece q ua ndo : fa lta m t rs d ias para o inic io do e ve nto 1. crac hs fo ra m e mit idos. Ps- cond : 1. crac hs so receb ido s pe los p art ic ipa ntes Emit ir cer t ificado s/ ce rt ificado s e mit idos Cate goria Verbo Ao rea lizad a pe la co mis so Aco ntece q ua ndo : fa lta um d ia p ara o t er mino do e ve nto 1. cert ificado s fora m e mit idos. Elabo rar p ro gra mao/ p ro gra mao Cate goria Verbo e laborada /at ua liza r progra ma o/pro gra ma o at ua lizada Ao rea lizad a pe la co mis so Aco ntece q ua ndo a co misso pos s ui pa le stra nte( s) e/o u minis tra nte e/o u aprese ntado r a se r inc ludo na pro gra ma o Pr- cond : 1. progra ma o fo i a t ua lizada. Cadastrar pa rce iros/ p arce iros cada str ados Cate goria Verbo Ao rea lizad a pe la co mis so Aco ntece q ua ndo a co misso po ss ui pa rce iros a se re m inc ludos pa ra um eve nto Pr- cond : 1. O eve nto e st abe rto 1. parce iro fo i cad ast rado. Selec io na r trab a lho/ traba lho se lec io nado Cate goria Verbo Ao rea lizad a pe lo co mit Aco ntece q ua ndo a co mit poss ui t raba lhos a se re m se lec io nados para um
5.Experimentao: Controle de Eventos Cientficos eve nto Pr- cond : Eve nto po ss ui va ga s nos hor r ios d e pro gra mao 1. traba lho fo i s e lec io nado. Fornec er rec ursos / rec ursos fo r nec ido s Cate goria Verbo Ao rea lizad a pe los pa rce iros Aco ntece q ua ndo o parce iro poss ui rec ursos pa ra o e ve nto Pr- cond : 1. parce iro est c adast rado para o e ve nto eve nto est e m abe rto 1. rec ursos fora m for nec idos. Receber p a ga me nto_rec urso/ Cate goria Verbo paga me nto_ rec urso receb ido Ao so fr ida pe los par ce iro s Aco ntece q ua ndo o parce iro t e m cr ed ito a recebe r Pr- cond : secret r ia e fet ua p a ga me nto ao for necedor 1. paga me nto_ rec urso fo i r eceb ido. Ps- cond : Clie nte / c lie nte e m pote nc ia l Cate goria Suje ito Pessoa q ue a inda no so lic ito u o cadas tro, ape na s c lie nte e m pote nc ia l Aes q ue e xec uta : 1. cons ulta r e ve nto s aber tos 2. cons ulta r e ve nto s fec hados 3. cons ulta r pro gra mao 4. so lic ita inscr io
127
I mpa cto S mbolo Noo I mpa cto
S mbolo Noo I mpa cto S mbolo Noo I mpa cto S mbolo Noo I mpa cto S mbolo Noo I mpa cto
inscr io Cate goria Objeto Ident ifica o de um c lie nte q ua ndo dese ja fa zer se u cad ast ro 1. a inscr io so lic itada pe lo c lie nt e a inda no inscr ito Solic itar inscr icao/ insc r io so lic itad a Cate goria Verbo Ao e xec utada pe lo s c lie nte Aco ntece q ua ndo o c lie nte te m inte resse e m se cada str ar e m um c ur so 1. inscr io fo i so lic itada. : Aberto /e m aberto /aber tos /e m abe rtos Cate goria Est ado So eve ntos q ue es to aco ntece ndo o u por aco ntece r Se ap lica ao s e ve ntos co m per odo de re a lizao ma ior o u igua l a da ta a t ua l Fechados / fec hado Cate goria estado So eve ntos q ue aco ntecera m Se ap lica ao s e ve ntos co m per odo de re a lizao me no r do q ue a da ta at ua l Vale salientar que os termos ou smbolos do LEL foram includos observando-
se o principio do vocabulrio mnimo e de circularidade. Pode-se verificar tambm que algumas restries existentes nos requisitos funcionais no foram includas (restries de tempo mnimo de 24 horas de
128
antecedncia, sete dias de antecedncia, entre outros) - . Estas restries sero includas parte, como uma restrio OCL a ser includa no LEL correspondente. Este tipo de informao torna-se til na confeco do diagrama, fazendo uma referncia explcita de restries a serem includas. A seguir foram includos os requisitos no funcionais de acordo com a tabela 5.5.
TABELA 5.5 INCLUSO DOS REQUISITOS NO FUNCIONAIS
Re quis ito f uncio na l pri m rio Segura na
Re quis itos no f unc io nais Re quis ito Es tra t gia es pe cfico s atis fao confide nc iab ilidade Identificao aute nt icao inte gr idade
Identificao
Segura na
aute nt icao
de S mbolo do LEL afe tado To das as ae s Pa ra to dos os aces s os To das as aes de atua li zao Pa ra to dos os aces s os de atua li zao
Observando a tabela 4.3 do captulo 4, pode-se verificar que vrios requisitos no funcionais, apesar de no explicitados no contexto, poderiam ser aplicados ao projeto, como: integridade, disponibilidade, usabilidade, entre outros. Porm, para exemplificao, foi utilizado apenas o requisito no funcional que diz respeito autorizao de acesso e autenticao (para acesso e atualizao dos dados). A seguir apresentado os requisitos organizacionais a serem includos no LEL atravs da tabela 5.6.
TABELA 5.6 INCLUSO DOS REQUISITOS ORGANIZACIONAIS
Re quis ito orga ni zacio nal Clie ntes VIP
Re quis itos orga ni zacio na is Es tra t gia de s atis fao S mbolo do LEL afe ta do Verificar potencial Validar situao Ap licar desco nto Emit ir car to- Clie nt e VIP Ins c rio e ve nto Ins c rio e ve nto Efe tua r Paga me nto Efe tua r paga me nto Ins c rio e ve nto
129
5.5.1 Analis ando inte rde pe nd nc ias e resolve ndo c onflitos

No nosso projeto, por termos poucos Requisitos no funcionais a serem satisfeitos e poucos requisitos organizacionais foi mais simples. Para cada requisito no funcional foi observado se a estratgia de satisfao era suficiente para operacionalizar o RNF e se ela contribua positivamente ou negativamente para isso. Esta informao muito til quando temos um sistema maior que envolve vrias autenticaes diferentes ou dupla confirmao, por exemplo. Apesar de ser uma influencia negativa sob o ponto de vista do usurio, 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 satisfao e influncia nos o utros termos do LEL. No nosso caso, no houve influencia negativa, pois as checagens requisitadas so mais simples.
5.5.2 Cons truindo os c e nrios

Para a construo de cenrios foi seguido o padro estabelecido por HADAD (1997), onde pode ser verificado com mais detalhes no anexo C. Porm, 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 verbo sujeito objeto
Cenrios Cenrio candidato Ator Recurso
Assim, ao final do processo os cenrios apresentados na tabela 5.8, s o elaborados com a incorporao dos requisitos no funcionais em azul, e organizacionais em verde e restries OCL em rosa. Em todos os impactos existentes devem ser tratados os requisitos no funcionais. De acordo com as regras definidas por Cysneiros (2002) este tratamento verificado a cada passo existente nos episdios. Porm, para facilitar o entendimento e a leitura, foi aplicada a restrio uma nica vez. Porm, caso seja necessrio, d e ve ser colocado a restrio extra no passo que a requer (como pode ser observado em alguns exemplos).

TABELA 5.8 CENRIOS DO LEL
130
Cons ultar e ve ntos e m aber to Proced ime nto para q ua ndo desej a- se conhe cer todo s os e ve ntos q ue es to e m aberto Siste ma e mit indo co ns ulta de e ve ntos e m aber to Secretr ia Tipo Pr im r io Ator Part ic ipa nte Tipo Pr im r io Ator Parce iro s Tipo Secund r io Ator Clie ntes inc luidos Tipo Pr im r io Ator Clie ntes Tipo Secund r io Ator Recursos eve nto Episdios 1. Siste ma e xibe e ve ntos e m aber to 2. Eve nto s e m abe rto so co ns ultados. Ttulo Cons ultar e ve ntos fec hados Objetivo Proced ime nto para q ua ndo desej a- se conhe cer todo s os e ve ntos q ue j ocorre ra m Contexto Siste ma e mit indo co ns ulta de e ve ntos fe c hados Atores Secretr ia Tipo Pr im r io Ator Part ic ipa nte Tipo Pr im r io Ator Parce iro s Tipo Secund r io Ator Clie ntes inc luidos Tipo Pr im r io Ator Clie ntes Tipo Secund r io Ator Recursos eve nto Episdios 1. Siste ma e xibe e ve ntos fec hados 2. Eve nto s fec hados so co ns ultados. Ttulo Alt erar pa rt ic ipa nte Objetivo Proced ime nto para q ua ndo desej a- se a lte rar o t ipo de pa rt ic ipa nte Contexto Siste ma e mit indo a lterao de p art ic ipa nte do e ve nto Atores Secretr ia Tipo Pr im r io Ator Comit Tipo Pr im r io Ator Recursos Eve nto Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. Secretr ia/ co mit id e nt ifica o p art ic ipa nte. 2. secret r ia /co mit se lec io na o e ve nto no q ua l o pa rt ic ipa nte de ve se r a lterado. 3. secre tr ia/co mit a lte ra o part ic ip a nte. Re str io : De ve t er inte gr idade, se ndo a estra t gia de sat is fao : ide nt ificao, a ute nt icao. Res tr io : min de 24 hora s de anteced nc ia da data inic io do e ve nto 4. part ic ipa nt e a lterado. Ttulo Objetivo Contexto Atores
5.Experimentao: Controle de Eventos Cientficos Ttulo Objetivo Contexto
131
Exc luir pa rt ic ipa nte Proced ime nto para q ua ndo desej a- se exc luir o par t ic ipa nte de um e ve nto Siste ma e mit indo e xc lus o de par t ic ipa nte no e ve nto Pr cond : Par t ic ipa nte infor ma por e- ma il s ua a us nc ia Atores Secretr ia Tipo Pr im r io Ator Recursos Eve nto Episdios . Rest r io : De ve ter co nfide nc iab il idade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. Secretr ia id e nt ifica o p art ic ipa nte 2. secret r ia se lec io na o e ve nto e m abe rto no q ua l o par t ic ipa nte de ve ser e xc luido. 3. secretr ia/co mit exc lui o part ic ipa nte. Res tr io : De ve te r inte gr idade, se ndo a estra t gia de sa t is fao : ide nt ificao, a ute nt icao. Re str io : min de 7 d ias te is d a data inic io do e ve nto 4. part ic ipa nt e e xc luido Ps- Cond : - Com exceo do par t ic ipa nte se r um o uvinte, se r enviado e- ma il pa ra os ouvinte s sobre a a ltera o e fe t uada. - Rest it uir va lor de insc r io para os o uvintes e/o u aprese ntador. Se pra zo da exc luso fo r ma ior q ue 5 d ias te is, o va lor a s er res t it udo ser de 80 % Ttulo Cons ultar pa rt ic ipa ntes Objetivo Proced ime nto par a q ua ndo dese ja- se co nhecer o s par t ic ipa ntes de um e ve nto e m aberto o u fe c hado Contexto Siste ma e mit indo co ns ulta de pa rt ic ipa nte no e ve nto Pr cond : Atores Secretr ia Tipo Pr im r io Ator Comisso Tipo Pr im r io Ator Recursos Eve nto Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. Se Secretr ia/Co miss o ide nt ifica o par t ic ipa nt e. Ento Se Sec ret r ia /co misso se lec io na t ipo de e ve nto Ento co ns ulta e ve nto s espec fic os co m pa rt ic ipa nte Seno co ns ult a e ve ntos co m par t ic ipa nt e. Seno Se Sec ret r ia /co misso se lec io na t ipo de e ve nto Ento co ns ulta todos o s par t ic ipa ntes do e ve nto se lec io nado Seno co ns ult a todos os p art ic ipa ntes e m todos o s e ve nto s 2. part ic ipa nt es so co ns ultado s. Ttulo Cadastrar e ve nto Objetivo Proced ime nto para q ua ndo receb ido pe la e mpre sa um e ve nto para gere nc iar Contexto Siste ma e mit indo cadas tro do e ve nto Pr cond : Atores Secretr ia Tipo Pr im r io Ator Recursos Eve nto Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o.
132
1. Secretr ia fo r nece infor maes sob re o e ve nto. 2. Secret r ia c adast ra e ve nto. Rest r io : De ve te r inte gr idade, se ndo a es tra t gia d e sat is fao : ide nt ificao, a ute nt icao. 3. eve nto cadas trado Ttulo Cadastrar co mis so Objetivo Proced ime nto para q ua ndo desej a- se cadast rar a co mis so or ga nizadora do e ve nto Contexto Siste ma e mit indo cadas tro da co mis so Pr cond : Atores Secretr ia Tipo Pr im r io Ator Recursos Eve nto Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. Secretr ia se lec io na e ve nto e m aber to. 2. Secretr ia fo r nece infor maes sob re a co misso. 3.Secretr ia cadas tra a co miss o. Res tr io : De ve te r inte gr idade, s e ndo a estra t gia de sat is fao : ide nt ificao, a ute nt icao. 4. Comisso cad ast rada Ttulo Cadastrar co mit Objetivo Proced ime nto para q ua ndo desej a- se cadast rar o co mit c ie nt fico do e ve nto Contexto Siste ma e mit indo cadas tro do co mit Pr cond : Atores Secretr ia Tipo Pr im r io Ator Recursos Eve nto Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. Secretr ia se lec io na e ve nto e m aber to. 2. Secretr ia fo r nece infor maes sob re o co mit. 3. Secretr ia cada stra o co mit. Res tr i o : De ve te r inte gr id ade, se ndo a es tra t gia d e sat is fao : ide nt ificao, a ute nt icao. 4. co mit cadas trado Ttulo Receber rec ur sos Objetivo Proced ime nto para q ua ndo for ne c ido re c ursos pe los pa rce iros para o e ve nto Contexto Siste ma e mit indo cadas tro de re c ursos receb ido s Pr cond : 1. rec ursos fora m for nec idos Atores Secretr ia Tipo Pr im r io Ator Recursos Eve nto, rec urso s Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. secret r ia se lec io na e ve nto aber to q ue poss ui rec ur so a receb er. 2. secre tar ia se lec io na r ec urso a r eceber. Re str io : De ve ter inte gr idade, se ndo a estra t gia de sat is fa o : id e nt ifica o, a ute nt ica o. 3. rec urso receb ido. Ttulo Objetivo Dis tr ib uir rec urso s Proced ime nto para q ua ndo d is tr ib udo os rec urso s para os e ve ntos
5.Experimentao: Controle de Eventos Cientficos Contexto
133
Siste ma e mit indo d is tr ib uio de rec urso s para os e ve ntos Pr cond : 1. rec ursos fora m receb idos pe la secre tar ia Atores Secretr ia Tipo Pr im r io Ator Recursos Eve nto, rec urso s Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. secret r ia se lec io na rec urso re ceb ido e no d ist r ib uido 2. secreta r ia se lec io na a t ivid ade (s ) do e ve nto a ser r e lac io nada co m rec ur so. Rest r io : De ve t er int e gr idad e, se ndo a estra t gia de sa t is fao : ide nt ifica o, aute nt icao. 3. rec urso d ist r ib uido. Pagar for necedo r Proced ime nto para q ua ndo o for necedor a inda no fo i pa go pe lo rec ur so for nec ido para o e ve nto Contexto Siste ma e mit indo pa ga me nto por rec urso receb ido do s e ve nto s Pr cond : 1. rec ursos fora m receb idos pe la secre tar ia Atores Secretr ia Tipo Pr im r io Ator Recursos Eve nto, rec urso Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. secret r ia se lec io na rec urso re ceb ido e no pa go 2. secre tar ia pa ga for necedo r do re c urso. Res tr io : De ve ter inte gr id ade, se ndo a estra t gia de sat is fa o : id e nt ifica o, a ute nt ica o. 3. fo r necedor p a go. Ps- cond : 1. Fornec edor rec ebe pa ga me nto_rec urso Ttulo Receber p a ga me nto Objetivo Proced ime nto par a q ua ndo a sec reta r ia a inda no recebe u pa ga me nto re fe re nte a inscr io do o uvinte e/o u ap rese ntador Contexto Siste ma e mit indo pa ga me nto de inscr io Pr cond : 1. Ouvint e e/o u ap rese nt ador es to ins cr itos no e ve nto 2. Ouvint e e/o u ap rese nt ador e fe t uo u pa ga me nto Atores Secretr ia Tipo Pr im r io Ator Recursos Eve nto, rec urso Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. secret r ia ide nt if ica o uvinte/ap rese ntador 2. secreta r ia rec ebe pa ga me nto. Res tr io : De ve te r inte gr idade, s e ndo a estra t gia de sat is fao : ide nt ificao, a ute nt icao. 3. paga me nto receb ido. Ttulo Objetivo Ttulo Objetivo Cons ultar p ro gra mao Proced ime nto para q ua ndo desej a- se conhe cer a pro gra ma o do e ve nto
5.Experimentao: Controle de Eventos Cientficos Contexto Atores
134
Siste ma e mit indo co ns ulta de pro gra ma o do e ve nto part ic ipa nt e Tipo Ato r Pr im r io parce iro s Tipo a tor pr ima r io c lie nte Tipo a tor secund ar io Clie nte inscr ito Tipo a tor pr ima r io Recursos Eve nto, p ro gra mao Episdios 1. part ic ipa nt e/par ce iro s/c lie nte/c lie nte inscr ito se lec io na e ve nto 2. part ic ipa nt e/par ce iro s/c lie nte/c lie nte inscr ito co ns ulta p ro gra mao do e ve nto. 3. progra ma o co ns ultada. Inscre ve r- se e m e ve nto Proced ime nto para q ua ndo o c lie nte inscr ito de seja se cadas trar e m um e ve nto Siste ma e mit indo cadas tro de inscr io no e ve nto Clie nte inscr ito Tipo a tor pr ima r io Eve nto, inscr io Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. c lie nte insc r ito se lec io na e ve nto e m aberto 2. c lie nte so lic it a inscr io. Rest r io : De ve ter inte gr idade, se ndo a es tra t gia d e sat is fao : ide nt ificao, a ute nt icao 3. Se CPF_c lie nte e nto inscr io cadas trada. . Res tr i o : Se Va lida r s it ua o ento ap licar de sco nto se no se ver if icar po te nc ia l e nto e mit ir car to. Pos cond : 1. efet uar p a ga me nto de ins cr i o Ttulo Envia r tr aba lho Objetivo Proced ime nto pa ra q ua nd o o aprese ntador dese ja e nviar trab a lho p ara se le o e m eve nto Contexto Siste ma e mit indo cadas tro de t raba lho Ator aprese ntado r Tipo a tor pr ima r io Recursos Eve nto, traba lho Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. aprese ntado r se lec io na e ve nto e m aber to 2. aprese ntado r ide nt ifica t raba lho. Res tr io : De ve te r inte gr idade, s e ndo a estra t gia de sat is fa o : id e nt ifica o, a ute nt ica o. 3. aprese ntado r cadas tra traba lho 4. traba lho e nviado. Ttulo Objetivo Contexto Atores Recursos Episdios Efe t uar pa ga me nto Proced ime nto para q ua ndo o o uvint e o u aprese ntador de seja m pa gar a inscr io e m um e ve nto Contexto Siste ma e fe t ua ndo pa ga me nto de inscr io no e ve nto Atores aprese ntado r Tipo a tor pr ima r io ouvinte Tipo a tor pr ima r io Recursos Eve nto, pa ga me nto Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. aprese ntado r/o uvinte s e lec io na e ve nto e m abe rto no q ua l esta insc r ito 2. aprese ntador /o uvinte e fet ua pa ga me nto. Res tr io : De ve te r inte gr idade, se ndo a Ttulo Objetivo
135
estra t gia de sa t is fao : ide nt ific ao, a ute nt ica o. Res tr io : Se va lidar c lie nt e ento ap licar de sco nto. 4. paga me nto e fet uado. Pos cond : 1. paga me nto receb ido p e la se cret r ia Ttulo Envia r pa le stra Objetivo Proced ime nto para q ua ndo o pa les tra nte dese ja e nvia r pa le stra p ara se leo e m eve nto Contexto Siste ma e mit indo cadas tro de inscr io no e ve nto Atores pa lest ra nte Tipo a tor pr ima r io Recursos Eve nto, pa les tra Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. pa lest ra nte se lec io na e ve nto e m abe rto 2. pa les tra nt e ide nt ifica pa les tra. Res tr io : De ve ter inte gr idade, se ndo a e stra t gia de sat is fao : ide nt ificao, a ute nt icao. 3. pa lest ra nte c adast ra pa le str a 4. pa lest ra e nviado. Envia r ma ter ia l Proced ime nto pa ra q ua ndo o min ist ra nte dese ja e nviar ma ter ia l para se le o e m eve nto Contexto Siste ma e mit indo cadas tro de inscr io no e ve nto Atores minis tra nte Tipo a tor pr ima r io Recursos Eve nto, mate r ia l Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. minis tra nte se lec io na e ve nto e m aber to 2. minis tra nte ide nt if ica mate r ia l. Res tr io : De ve ter inte gr idade, se ndo a estra t gia de sat is fao : ide nt ificao, a ute nt icao. 3. minis tra nte cada stra mat er ia l 4. mater ia l e nviado. Ttulo Objetivo Ttulo Objetivo Contexto Atores Recursos Episdios Envia r req uis io Proced ime nto para q ua ndo o minis tra nte dese ja e nvia r req uis iao e m e ve nto Siste ma e mit indo cadas tro de req uis iao no e ve nto minis tra nte Tipo a tor pr ima r io Eve nto, req uis iao Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. minis tra nte se lec io na e ve nto e m aber to 2. minis tra nt e id e nt ifica req uis io. Res tr io : De ve te r inte gr idade, se ndo a estra t gia de sat is fa o : id e nt ifica o, a ute nt ica o. 3. minis tra nte cada stra req uis io 4. requis io e nviada. Selec io na r minis tra nt e Proced ime nto para q ua ndo desej a- se se lec io nar o minis tr a nte pa ra o e ve nto Siste ma e mit indo se le o de minis tra nte
Ttulo Objetivo Contexto
136
Atores co miss o Tipo a tor pr ima r io Recursos Eve nto Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. co miss o se le c io na va ga s nos hor r ios de p ro gra mao do e ve nto e m abe rto 2. co mis so ide nt ifica minis tra nt e. Rest r io : De ve te r inte gr idade, se ndo a estra t gia de sat is fa o : id e nt ifica o, a ute nt ica o. 3. co miss o cadas tra minis tra nte 4. minis tra nte se lec io nado. Pos cond : 1. e nviado e- ma il pa ra o minis tra nte co m o co nvite do e ve nto co nte ndo : ass unto d e intere sse do curso, pra zo est imado para o e nvio do mate r ia l e ace ita o do convite e infor maes ge ra is sobre o e ve nto Ttulo Selec io na r pa les tra nte Objetivo Proced ime nto para q ua ndo desej a- se se lec io nar o pa lest ra nte p ara o e ve nto Contexto Siste ma e mit indo se le o de pa le str a nte Atores co miss o Tipo a tor pr ima r io Recursos Eve nto Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. co miss o se le c io na va ga s nos hor r ios de p ro gra mao do e ve nto e m abe rto 2. co mis so id e nt ifica pa les tra nte. Res tr i o : De ve ter inte gr idade, se ndo a e stra t gia de sat is fao : ide nt ificao, a ute nt icao. 3. co miss o cadas tra pa lest ra nte 4. pa lest ra nte se lec io nado. Pos cond : 1. e nviado e- ma il pa ra o pa lest ra nte co m o co nvite do e ve nto co nte ndo : a ss unto d e intere sse do c urso, p ra zo est imado pa ra o e nvio da pa le str a e ace itao do co nvite e requis io e infor maes ger a is sob re o e ve nto Ttulo Emit ir cra c hs Objetivo Proced ime nto para q ua ndo desej a- se e mit ir crac hs p ara os pa rt ic ipa ntes do e ve nto Contexto Siste ma e mit indo crac h s para pa rt ic ipa ntes Atores co miss o Tipo a tor pr ima r io Recursos Eve nto, c rac h Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. co miss o se le c io na e ve nto e m ab erto 2. co miss o se le c io na pa rt ic ipa ntes do e ve nto 3. co miss o so lic ita impres so do crac h 4. crac h e mit ido. Pos cond : 1. crac h e nviado ao par t ic ipa nte Ttulo Emit ir cer t ificado s Objetivo Proced ime nto para q ua ndo d eseja- se e mit ir ce rt ific ado de par t ic ipao para o s part ic ipa nt es do e ve nto Contexto Siste ma e mit indo crac h s para pa rt ic ipa ntes Atores co miss o Tipo a tor pr ima r io Recursos Eve nto, c ert if icado Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao :
137
id e nt ifica o, a ute nt ica o. 1. co miss o se le c io na e ve nto fec hado. 2. co miss o se le c io na pa rt ic ipa ntes do e ve nto. Co m no mni mo 85% pre se na. 3. co miss o so lic ita impres so do cer t ificado 4. cert ificado e mit ido. Pos cond : 1. cert ificado e nviado ao pa rt ic ipa nte Ttulo At ua liza r pro gra mao Objetivo Proced ime nto para q ua ndo desej a- se e labora r a pro gr a mao do e ve nto Contexto Siste ma e mit indo at ua liza o da par t ic ipa ntes Atores co miss o Tipo a tor pr ima r io Recursos Eve nto, p ro gra mao Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. co miss o se le c io na e ve nto e m ab erto. 2. co miss o ide nt ifica pro gra ma o. 3. co mis so at ua liza pro gra mao. Res tr io : De ve t er inte gr idade, se ndo a estra t gia de sat is fa o : id e nt ifica o, a ute nt ica o. 4. progra ma o at ua lizad a. Cadastrar pa rce iros Proced ime nto para q ua ndo desej a- se cadast rar par ce iro s nos e ve ntos Siste ma e mit indo o cadas tro de par ce iro s co miss o Tipo a tor pr ima r io Eve nto Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. co miss o se le c io na e ve nto e m ab erto. 2. co misso ide nt ific a parce iros. Re st r io : De ve te r inte gr idade, se ndo a e stra t gia de sat is fao : ide nt ificao, a ute nt icao. 3. parce iro s so cada strado s. Ttulo Selec io na r trab a lho Objetivo Proced ime nto par a q ua ndo dese ja- se se le c io nar trab a lhos a sere m apre se ntado s no eve nto Contexto Siste ma e mit indo a se leo de t raba lho s Atores co mit Tipo a tor pr ima r io Recursos Eve nto, p ro gra mao, t raba lho s Episdios Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. co mit se le c io na e ve nto e m ab erto. 2. Comit se lec io na pro gra mao 2. co mit ide nt if ica traba lho. Res tr io : De ve te r inte gr idade, se ndo a es trat gia d e sat is fao : ide nt ificao, a ute nt icao. 3. traba lho se le c io nado. Pos cond : 1. e nviado e- ma il par a o aprese ntador par abe niza ndo pe lo tr aba lho se lec io nado e seu ho rr io pre visto de ap rese ntao e so lic itao do p a ga me nto da ins cr i o no eve nto Ttulo Fornec er rec ursos Ttulo Objetivo Contexto Atores Recursos Episdios
5.Experimentao: Controle de Eventos Cientficos Objetivo Contexto Atores Recursos Episdios
138
Atores Recursos Episdios 1. se lec io nar t ipo c lie nte 2. Se t ipo_c lie nt e = vip e nto re tor na tr ue se no reto r na fa lse Ttulo Objetivo Contexto
Proced ime nto para q ua ndo desej a- se cadast rar re c ursos pa ra o e ve nto Siste ma e mit indo cadas tro de re c ursos parce iro s Tipo a tor pr ima r io Eve nto Rest r io : De ve ter co nfide nc iab ilidade, se ndo a es tra t gia de sa t is fao : id e nt ifica o, a ute nt ica o. 1. parce iro s se lec io na e ve nto e m aberto co m re c ursos a recebe r por e le. 2. parce iro ide nt ifica rec urso. Res tr io : De ve ter inte gr idade, se ndo a es tra t gia d e sat is fao : ide nt ificao, a ute nt icao. 3. rec urso for nec ido. Pos cond : 1. secreta r ia recebe r ec ursos Va lidar s it uao Proced ime nto para q ua ndo desej a- se ve r ificar s it uao do c lie nt e insc r ito Siste ma re tor na t r ue para o caso de se r um c lie nte vip, ca so co nt rar io reto r na fa lse Pr- cond : 1. recebe co mo e ntrada a ide nt ificao do c lie nte inscr ito RO Tipo a tor
Atores Recursos Episdios 1. retor na va lor inscr io := va lor inscr io- 30% Ttulo Objetivo Contexto
Ap licar desco nto Proced ime nto para q ua ndo desej a- se ve r ificar s it uao do c lie nt e insc r ito Siste ma re tor na va lor inscr io co m de sco nto ap licado de 3 0% 1. recebe co mo e ntrada va lor inscr iao RO Tipo a tor
Atores Recursos Episdios 1. se lec io nar to ta l de e ve ntos a nua is nos q ua is o c lie nte inscr ito par t ic ipo u 2. Se tota l > 3 e nto retor na tr ue se no re tor na fa lse Ttulo Objetivo Contexto Emit ir car to Proced ime nto para q ua ndo desej a- se e mitr ca rto vip Siste ma e mit indo car toVIP Pr- cond : 1. recebe co mo e ntrada a ide nt ificao do c lie nte inscr ito RO Tipo a tor 1. Carto impres so
Ver ifica r pote nc ia l Proced ime nto para q ua ndo desej a- se ve r ificar o po te nc ia l do c lie nte ins cr ito Siste ma re tor na tr ue para o caso de se r um c lie nte vip e m po te nc ia l, ca so co nt rar io retor na fa ls e Pr- cond : 1. recebe co mo e ntrada a ide nt ificao do c lie nte inscr ito RO Tipo a tor
Atores Recursos Episdios
139
Atores Recursos Episdios
CPF_c lie nte Proced ime nto pa ra q ua ndo de seja- se sab er a s it uao j unto aos r gos co mpe te nte s sobre a s it uao do c lie nte Siste ma e mit indo CPF_Clie nte Pr- cond : 1. recebe co mo e ntrada o CPF do c lie nt e s iste ma Tipo a tor 1. Cons ulta r go s co mpe te nte s 2. retor na tr ue s e s it uao ok, se no reto r na fa lse
5.5.3 Analis ando os ce nrios

Vale observar que muitos cenrios sero includos nesta fase, pois nem todos os cenrios identificados ao se descrever os episdios3 foram definidos no LEL como verbo, observando-se as regras para construo de cenrios de acordo com o LEL (Leite, 1997). Um outro ponto interessante foi a incluso das estratgias de satisfao dos requisitos organizacionais como cenrios. A anlise dos cenrios est ligada ao fato de que precisamos validar e verificar os cenrios com os clientes a fim de identificar erros, omisses e/ou ampliar informaes de episdios. Seguindo os passos para a construo de cenrios deve-se unificar os cenrios se eles possurem o mesmo objetivo ou mesmos episdios.
5 .6 F a se 3 De fini o de A s pe c to s Ca ndida to s
A definio dos aspectos candidatos foi realizada seguindo as diretrizes propostas no captulo 4. Assim, primeiramente, identificamos os requisitos no funcionais como
aspectos candidatos, outros aspectos podem ser identificados levando-se em considerao os outros passos das diretrizes apontadas na fase 3.
3
Cysneiros (2002) realiza a descrio dos cenrios de forma bem sucinta, sendo de poucas palavras, utilizando-se o principio do vocabulrio mnimo, no sendo portanto, rico em detalhes. Breitman (2000) descreve os cenrios de forma bem detalhada, inclusive fazendo referencias as telas usadas no acesso. Usaremos o meio termo, no seremos to detalhistas e nem to vagos nas nossas descries. Quando a situao for julgada necessria, seremos mais detalhistas.
140
Deste modo, foram identificados quatro aspectos candidatos no nosso estudo de caso: Confidenciabilidade Requisito no funcional requisitado pela maioria dos cenrios; Integridade - Requisito no funcional requisitado por todos os cenrios onde exige a atualizao; CPF_Cliente foi definido como aspecto por se tratar de uma restrio que pode ser aplicada em outros cenrios e outros projetos, sem que a funcionalidade bsica seja alterada caso venha a ser retirado; Validar Situao foi definido como aspecto por se tratar de uma constraint organizacional que pode ser aplicada em outros cenrios e em outros projetos. A tabela 5.9 relaciona os aspectos encontrados com os cenrios correspondentes e sua influncia sobre eles.

TABELA 5.9 CONTRIBUIES DOS ASPECTOS
141
identificador
Aspectos Candidatos Confidenciabilidade Integridade CPF_Cliente Validar Cenrio Situao
Alt erar part ic ipa nt e Exc luir part ic ipa nt e Cons ultar part ic ipa nt es Cadastrar e ve nto Cadastrar co miss o Cadastrar co mit Receber rec ur sos Dis tr ib uir rec urso s Pagar for necedo r Receber paga me nto Cons ultar progra ma o Inscre ve r- se e m eve nto Envia r tr aba lho Efe t uar paga me nto Envia r pa le stra Cadastrar parce iro s Envia r ma ter ia l Emit ir cer t ificado s At ua liza progra ma o Selec io na r traba lho Fornec er rec ursos Selec io na r minis tra nte Selec io na r pa lest ra nte Emit ir cra c hs Envia r req uis io
+
X X X X X X X X X X X X X X X X X X X X X X X X X
+
X X
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
X X X X X X X
X X X X X X X X X X X X X X
X X
142
O aspecto CPF_Cliente apesar de inicialmente se tratar de uma restrio onde o usurio 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 informaes que esto sendo prestadas, ou seja, o cliente fidedigno. Para definir a composio entre os aspectos, ou seja, como ser realizada a chamada para a execuo 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 . COMPOSIO DOS ASPECTOS IDENTIFICADOS ASPECTO CANDIDATO: AC#1 - Confidenciabilidade CENARIO AFETADO CN # 1 - A lterar p articip an te CN # 2 - Exc lu ir p articip an te
CONDIO
REGRA DE
COMPOSIO
PONTO DE
JUNO
INFORMAES ADICIONAIS Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro)
WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP -
CN # 3 - Co n s u ltar p articip an tes CN # 4 - Cad as trar ev en t o
CN # 5 - Cad as trar co mis s o CN # 6 - Cad as trar co mit CN # 7 - Receb er re c u rs os CN # 8 - D is trib u ir re c u rs os CN # 9 - Pag ar fo rn e c e d o r CN # 1 0 - Receb er p ag amen to

CN # 1 1 - Co n s u ltar p ro g ramao C N # 1 2 - In s c re v e r-s e em ev en t o CN # 1 3 - En v ia r trab alh o C N # 1 4 - E fe t u a r p ag amen to CN # 1 5 - En v ia r p ales tra CN # 1 6 - Cad as trar p arceiro s CN # 1 7 - En v ia r mater ia l CN # 1 8 - Emit ir certif icad o s CN # 1 9 - A tu aliza p ro g ramao CN # 2 0 - Se lec io n ar trab alh o CN # 2 1 - Fo rn ecer re c u rs os WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro)
143
CN # 2 2 - Se lec io n ar min is tran te CN # 2 3 - Se lec io n ar p ales tran te
CN # 2 4 - Emit ir c ra c h s CN # 2 5 - En v ia r req u is io

ASPECTO CANDIDATO: AC#2 CENARIO AFETADO
144
Integridade
REGRA DE
COMPOSIO
CONDIO
PONTO DE
JUNO
INFORMAES ADICIONAIS
CN # 1 - A lterar p articip an te
WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP -
Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro)
CN # 2 - Exc lu ir p articip an te
CN # 4 - Cad as trar ev en t o
CN # 5 - Cad as trar co mis s o
CN # 6 - Cad as trar co mit
CN # 7 - Receb er re c u rs os
CN # 8 - D is trib u ir re c u rs os
CN # 9 - Pag ar fo rn e c e d o r
CN # 1 0 - Receb er p ag amen to
C N # 1 2 - In s c re v e r-s e em ev en t o
CN # 1 3 - En v ia r trab alh o
C N # 1 4 - E fe t u a r p ag amen to
CN # 1 5 - En v ia r p ales tra

CN # 1 6 - Cad as trar p arceiro s WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP WRAP 1 1 1 1 1 1 1 1 1 1 Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) Se situaoOK ento executa(ponto juno) Seno exibe(msgErro)
145
CN # 1 7 - En v ia r mater ia l
CN # 1 8 - Emit ir certif icad o s
CN # 1 9 - A tu aliza p ro g ramao
CN # 2 0 - Se lec io n ar trab alh o
CN # 2 1 - Fo rn ecer re c u rs os
CN # 2 2 - Se lec io n ar min is tran te
CN # 2 3 - Se lec io n ar p ales tran te
CN # 2 4 - Emit ir c ra c h s
CN # 2 5 - En v ia r req u is io
ASPECTO CANDIDATO: AC#3 - CPF_CLIENTE
CENARIO AFETADO
CONDIO
REGRA DE
COMPOSIO
PONTO DE
JUNO
CN #12 - Ins creve rse e m eve nto
wrap
Se situaoOK ento executa(ponto juno) Seno exibe(msgErro)
ASPECTO CANDIDATO: AC#4 - VALIDAR SITUAO CENARIO AFETADO

CONDIO
REGRA DE
COMPOSIO
PONTO DE
JUNO

CN #12 - Ins creve r- se e m eve nto
CN # 1 4 pag a me nt o Efe tu ar overlap.after| 3 Se situaoOK ento executa(ponto juno) Seno exibe(msgErro) SE SITUAOOK ENTO EXECUTA(PONTO JUNO) SENO EXIBE(MSGERRO)
146
overlap.before|
Agora se deve verificar se no h conflitos entre os aspectos candidatos. Eles so identificados quando diferentes aspectos candidatos devem ser aplicados num mesmo ponto de juno de um cenrio com os mesmos operadores de composio. Neste projeto, os aspectos relacionados confiabilidade e integridade esto com os mesmos operadores e mesmo pontos de juno. Assim, deve-se aplicar uma ordem de precedncia para definir qual ser executado primeiro. No capitulo 4 descreve-se com mais detalhes como fazer esta operao. A tabela 5.11 apresenta a resoluo dos conflitos.
TABELA 5.11 RESOLUO DE CONFLITOS
Cenrios CN #1 - Alter ar par t ic ipa nte CN #2 - Exc luir par t ic ipa nte CN #4 - Cadastrar e ve nto CN #5 - Cadastrar co misso CN #6 - Cadastrar co mit CN #7 - Receber rec ursos CN #8 - Dist r ib uir rec ursos CN #9 - Pagar fo r necedor CN #10 - Receber paga me nto CN #12 - Inscre ver- se e m e ve nto CN #13 - Enviar traba lho CN #14 - Efet ua r pa ga me nto CN #15 - Enviar pa les tra CN #16 - Cadastrar parc e iro s CN #17 - Enviar mate r ia l CN #18 - Emit ir cert if icados CN #19 - Atua liza pro gr a mao CN #20 - Selec io nar traba lho CN #21 - Fornecer rec ur sos CN #22 - Selec io nar minis t ra nte CN #23 - Selec io nar pa lest ra nte CN #24 - Emit ir crac hs CN #25 - Enviar req uis io
AC#1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1 P1-W =1
AC#2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2 P1-W =2
147
Observando a tabela 5.11 podemos deduzir que o aspecto candidato AC #1Confiabilidade ser executado antes do aspecto candidato AC #2 Integridade. Decises como estas devem ocorrer com vrios aspectos a serem includos nos projetos. importante que seja tomado uma deciso por parte do gerente de projeto, clientes e engenheiro de requisitos.
5 .7 F a se 4 Ma pe a me nto de O nto lo g ia s
Nesta fase aplicaremos o mtodo proposto por Breitman (2003). Neste mtodo, os termos do lxico classificados como do tipo objeto e sujeito sero mapeados em classes da ontologia; os termos classificados em verbo sero mapeados para propriedades; os termos classificados como do tipo estado sero mapeados para classes ou propriedades, dependendo de sua importncia relativa para a ontologia; a noo de cada termo mapeada na descrio da respectiva classe; e atravs da lista de impactos de cada termo do lxico mapeia-se o verbo em propriedades e o predicado em restries das classes. A tabela 4.9, apresentada no Captulo 4 apresenta um resumo das aes 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 construo de ontologia do gerenciamento de eventos.
148
1 Listar os termos alfabeticamente de acordo com seu tipo (verbo, objeto, sujeito ou estado) 2 Fazer trs listas: Propriedades, classes e axiomas. Na lista de classes cada entrada ter um nome, descrio (linguagem natural) e uma lista contendo zero ou mais restries (funo que relaciona a classe em questo a outras, de maneira no-taxonmica). As entradas na lista de axiomas tero nomes (labels) somente. 3 Utilizando a lista de smbolos do lxico classificados como sujeito ou objeto, para cada termo: 3.1 Adicionar uma nova classe a lista de classes. O nome da classe o smbolo do lxico propriamente dito. A descrio da classe a noo do termo. 3.1.1 para cada impacto, 3.1.1.1 checar se j no faz parte da lista de propriedades da ontologia 3.1.1.2 - Caso no faa parte da lista (a propriedade ainda no 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 consistncias 3.1.1.3 Na lista de classes, adicionar uma nova restrio para a classe em questo. A restrio 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 smbolo do lxico. Usualmente um termo do prprio lxico e aparece sublinhado) 3.1.1.4 Checar se existem indicativos de negao no vocabulrio mnimo que relacionem duas ou mais classes. Verificar se essas classes possuem um relacionamento do tipo disjuntos(exemplo: macho e fmea). 3.1.1.4.1 Se verdadeiro, adicionar o disjoint a lista de axiomas. 3.2 Verificar consistncia 4 Utilizando a lista de smbolos 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 no faa parte da lista (a propriedade no existe), adicionar uma nova propriedade a lista (de propriedades). O nome da propriedade o smbolo do lxico propriamente dito. 4.1.1.1.1 - Verificar consistncia 5 Utilizando a lista de smbolos classificados como tipo estado, para cada termo: 5.1.1 Para cada impacto. 5.1.1.1 Tentar identificar a importncia relativa do termo para a ontologia. Essa estratgia similar a utilizao de questes de competncia proposta por Gruninger (1995). Essas questes so obtidas atravs do refraseamento dos impactos de cada smbolo em perguntas iniciadas por quando, onde o que, quem , por que e como. 5..1.1.2 - Checar se existem indicativos de negao no vocabulrio mnimo que relacionem duas ou mais classes. Verificar se essas classes possuem um relacionamento do tipo disjunto (exemplo: macho e fmea). 5.1.1.2.1 Se verdadeiro, adicionar o disjoint a lista de axiomas 5.1.1.3 - Checar se possvel criar uma partio de valor. 5.1.1.3.1 Criar uma classe pai para a partio 5.1.1.3.2 - Fazer com que as classes participantes da partio 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 no central para a ontologia), classifique-o como propriedade (R). 5.1.4 Verificar consistncia.
FIGURA 5.3 O PROCESSO DE MAPEAMENTO LEL ONTOLOGIAS. BREITMAN(2003)
149
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 alterar participante cadastrar cliente cadastrar comisso cadastrar comit cadastrar parceiros consultar eventos em aberto consultar eventos fechados consultar participante distribuir recursos efetuar inscrio efetuar pagamento elaborar programao emitir certificados emitir crachs enviar material enviar palestra enviar requisio enviar trabalho excluir participante fornecer recursos pagar fornecedor receber pagamento receber recursos selecionar ministrante selecionar palestrante, solicitar inscrio
Sujeito Apresentador Cliente Cliente inscrito Comisso Comit Fornecedor Ministrante Ouvinte Palestrante Participante Patrocinador Secretria
Objeto Certificado Crach Evento Inscrio Material Pagamento Palestra Programao Recurso Trabalho
Estado Aberto Fechado
2 Fazer trs listas: Propriedades, classes e axiomas. Na lista de classes cada entrada ter um nome, descrio (linguagem natural) e uma lista contendo zero ou mais restries (funo que relaciona a classe em questo a outras, de maneira notaxonmica). As entradas na lista de axiomas tero nomes (labels) somente. Propriedade Classe Axioma
150
3 Utilizando a lista de smbolos do lxico classificados como sujeito ou objeto, para cada termo:
3.1 Adicionar uma nova classe a lista de classes. O nome da classe o smbolo do lxico propriamente dito. A descrio da classe a noo do termo.
3.1.1 para cada impacto, 3.1.1.1 checar se j no faz parte da lista de propriedades da ontologia 3.1.1.2 - Caso no faa parte da lista (a propriedade ainda no 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 consistncias 3.1.1.3 Na lista de classes, adicionar uma nova restrio para a classe em questo. A restrio 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 smbolo do lxico. Usualmente um termo do prprio lxico e aparece sublinhado) 3.1.1.4 Checar se existem indicativos de negao no vocabulrio mnimo que relacionem duas ou mais classes. Verificar se essas classes possuem um relacionamento do tipo disjuntos(exemplo: macho e fmea). 3.1.1.4.1 Se verdadeiro, adicionar o disjoint a lista de axiomas. 3.2 Verificar consistncia
TABELA 5.13 MAPEAMENTO REALIZADO
Propriedades
-enviado -selecionado -apresentado -alterado -consultado -inscrito -elaborado -enviado -emitido -fornecido -pago -solicitado -excludo -distribudo
Axioma Classes
Trabalho pode ser: full, short, poster

- Apresentador Descrio: Cliente inscrito para apresentar trabalho - Trabalho Descrio: Artig os a serem apresentados em um evento - comit Descrio: Grup o de pessoas selecionadas para selecionar os trabalhos apresentados no evento - participante: Descrio: P essoa que partic ipa de um event o como : o uv inte, apresentador,

palestrante, min istrante
151
- evento: Descrio: Conferncia ou Worksh op a ser gerenciado pela empresa. Cada evento possui u m perodo de realizao. - cliente_inscrito Descrio: P essoa que solic ito u o cadastro e foi aprovada, recebendo o seu log in e senha - programao: Descrio: Cronograma a ser cumprid o do evento Contem as palestras, trabalhos e cursos a serem apresentados no evento - comisso Descrio: Gru po de pessoas selecionadas para gerenciar o evento. - ministrante Descrio: Cliente inscrito para ministrar curso - material Descrio: O mate r ia l re fere nte ao c urso a ser min ist rado e m um e ve nto - requisio Descrio: Documento que contem referencias aos recursos materiais
necessrios para realizar a tarefa

- palestrante Descrio: Cliente inscrito para ministrar palestra -palestra Descrio: Slides referentes a um assunto a ser apresentado no evento - crach Descrio: Ide nt ificao do pa rt ic ipa nte do e ve nto - certificado Descrio: Co mpro va nte de par t ic ipao do e ve nto - patrocinador Descrio: Empresa que fornecem recursos financeiros para a realizao do evento - recursos Descrio: So materiais necessrios para a realizao e elaborao do
evento. Podem ser: financeiro, humano e material

- pagamento Descrio Comprovante de quitao com o evento - ouvinte Descrio: Cliente inscrito para assistir aos cursos, palestras e apresentaes do evento
152
- cliente Descrio: Pessoa q ue a inda no so lic ito u o c adast ro, ape nas c lie nte e m
pote nc ia l
- inscrio Descrio Ident ific ao de um c lie nte q ua ndo de seja fa zer s e u cadas tro - secretria Descrio: P essoa que auxilia no gerenciamento d o evento - fornecedor Descrio: Empresa que fornece recursos (materiais ou humanos) para a realizao do evento
4 Utilizando a lista de smbolos 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 no faa parte da lista (a propriedade no existe), adicionar uma nova propriedade a lista (de propriedades). O nome da propriedade o smbolo do lxico propriamente dito. 4.1.1.1.1 - Verificar consistncia Todos os verbos foram mapeados. 5 Utilizando a lista de smbolos classificados como tipo estado, para cada termo: 5.1.1 Para cada impacto. 5.1.1.1 Tentar identificar a importncia relativa do termo para a ontologia. Essa estratgia similar a utilizao de questes de competncia proposta por Gruninger. Essas questes so obtidas atravs do refraseamento dos impactos de cada smbolo em perguntas iniciadas por quando, onde o que, quem , por que e como. 5..1.1.2 - Checar se existem indicativos de negao no vocabulrio mnimo que relacionem duas ou mais classes. Verificar se essas classes possuem um relacionamento do tipo disjunto (exemplo: macho e fmea). 5.1.1.2.1 Se verdadeiro, adicionar o disjoint a lista de axiomas 5.1.1.3 - Checar se possvel criar uma partio de valor. 5.1.1.3.1 Criar uma classe pai para a partio 5.1.1.3.2 - Fazer com que as classes participantes da partio 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 no central para a ontologia), classifique-o como propriedade (R). 5.1.4 Verificar consistncia.
Seguindo os passos acima criamos duas novas classes referentes ao estado de aberto e fechado, com restrio de disjuno entre elas.
153
Foi criada uma classe de partio de valor chamada: tipo_evento, onde possui referencia as outras classes de aberto e fechado. Assim, ficou conforme demonstra a figura 5.4.
Classes Aberto Definio: so os eventos que possuem o perodo de realizao maior ou igual do que a data atual subClasseOf: tipo-evento Fechado Definio:so os eventos que possuem o perodo de realizao menor do que a data atual subClasseOf: tipo-evento Tipo-Evento Definio: conjunto dos estados possveis em que o evento pode estar no momento.Partio de valor.
FIGURA 5.4 MAPEAMENTO DOS SMBOLOS DO TIPO ESTADO
A ltima etapa do processo de construo de ontologias a construo de uma hierarquia de classes, onde identificamos conceitos que possam estar relacionados hierarquicamente. No topo da ontologia fica o termo mais genrico, e nas suas folhas os mais especficos. 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 restries idnticas 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 faam 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 consistncia. Foram identificadas as seguintes listas:
154
Parceiros - fornecedor - patrocidador Cliente - cliente inscrito - cliente - participante (ouvinte, palestrante, apresentador, ministrante) Recursos -materiais ou humanos -financeiros Material_evento -palestra -curso -apresentao - requisio Grupo_trabalho - secretria - comit - comisso Objetos_evento - crach - certificado - programao
FIGURA 5.5 ESTRUTURA HIERRQUICA DA ONTOLOGIA EVENTOS
5 .8 Ge ra o de A rquiv o s pa ra Ex po rta o
Atualmente busca-se de um modo geral uma interoperabilidade entre ferramentas de desenvolvimento que nem sempre possvel de se obter. A exportao de documentos no padro XML permite que se obtenha esta interoperabilidade, mesmo que de forma simples, porm eficiente. Uma vez que tenhamos o documento XML gerado e o padro a ser obedecido por ele (seja atravs de uma DTD ou de um XML Schema) podemos garantir a padronizao e a leitura do mesmo. Assim, atravs do padro estabelecido no Capitulo 4 atravs d o s XML Schemas, foram gerados documentos prontos para exportao.
155
Estes documentos na sua ntegra esto no Anexo C, porm seguem alguns trechos do mesmo:
... <Projeto> <id_projeto>1 <dominio>comunicao <nome_projeto>Eventos <descricao>Controle de Eventos Cientficos <LEL> <id_simbolo>1</id_simbolo> <nome_simbolo>fechado</nome_simbolo> <categoria>estado</categoria> <sinonimos> <alias> fechados</alias> ....
Figura 5.6 Trecho do Arquivo do LEL dos Smbolos em XML
... <Projeto> <id_projeto>1 <dominio>comunicao <nome_projeto>Eventos <descricao>Controle de Eventos Cientficos <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.7 Trecho do Arquivo do LEL dos Cenrios em XML
156
... <Aspectos> <nome>validar situao</nome> <origem>RO</origem> <descricao>validar situao do cliente inscrito</escricao> ...
Figura 5.8 Trecho do Arquivo de Aspectos XML
... <ontologias> <classe> <nome>comit</nome> <descricao>Grupo de pessoas que avaliam os trabalhos para apresentao no evento</descricao> <restricao></restricao> ...
Figura 5.9 Trecho do Arquivo de Ontologias XML
157
Neste captulo realizamos o estudo de caso referente abordagem proposta. Ficou claro, a partir da anlise efetuada, que a abordagem DAORE permite um tratamento diferenciado para os requisitos funcionais, no funcionais e organizacionais. Alm de incorporar a identificao dos aspectos candidatos (ponto chave em Early Aspects). A identificao 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 exportao do arquivo em XML baseado no Schema XML do LEL, ontologias e casos de uso e aspectos. Esta especificao
permite a interoperabilidade entre ferramentas, pois o desenvolvedor pode ter a flexibilidade de escolha da ferramenta mais apropriada ao seu uso. Em um ambiente distribudo de desenvolvimento, esta flexibilidade fundamental, pois a equipe de desenvolvimento no est presa a uma ferramenta padro. A autora acredita que a gerao de um arquivo XML dos casos de uso seguindo a MDSODI um facilitador pois mesmo que no possa construir graficamente este recurso permite a definio dos principais cenrios do sistema e de seus atores seguindo a metodologia MDSODI. Sendo um recurso poderoso e aliado na especificao do domnio do sistema. Assim, a abordagem DAORE provou que alm de facilitar a identificao dos aspectos candidatos, permite que sejam definidos parmetros fundamentais para que se possa atingir a prxima etapa do desenvolvimento, com a elaborao dos casos de uso.
6. A Ferramenta Requisite e a Abordagem DAORE
158
CAPTULO
6
A FERRAMENTA R EQUISITE E A ABORDAGEM DAORE
Termos conscincia de que somos ignorantes um grande passo rumo ao saber. Disraeli
Es te c ap tulo apres enta uma a n lis e da f erra menta Requis it e e m s ua prime ira vers o e a vers o atua l, bas eada na exper ime nta o efetuada. realizado uma an lis e do impac to que es s a mudan a ir provoc ar no projeto DiSEN, s eus pros e c ontras . Por fim, ava liamos s e as mudan as s o nec ess rias para o futuro do projeto DiSEN.
6 .1 Situa o At ua l
A ferramenta Requisite desenvolvida em Java no aplicativo NetBeans, possui algumas limitaes referentes a orientao a aspectos, mesmo porque, na sua concepo no havia referencia na literatura sobre o assunto. Foi desenvolvida usando a orientao a objetos e, como j foi visto no captulo 2, a orientao a objetos no contempla de forma eficiente a identificao e composio das propriedades transversais de um projeto de software. Deste modo, algumas mudanas so necessrias para que se pudesse dispor de algumas facilidades e contribuies da abordagem DAORE, como: ontologias, definies dos requisitos no funcionais e suas operacionalizaes, definio dos requisitos organizacionais, importao atravs de um padro pr-definido destes dados e,
159
principalmente, a identificao dos aspectos candidatos em um projeto a ser desenvolvido no ambiente DiSEN. As mudanas seriam bastante significativas justificando, inclusive, em uma nova verso, como no caso da alterao efetuada na ferramenta OORNF. O trabalho de Wiese (2006) aborda a questo de interoperabilidade entre as ferramentas de desenvolvimento, realizando um trabalho de transformao do modelo de casos de uso, entre as ferramentas: Poseidon1 , Enterprise Architect2 e a Requisite. Seu trabalho no seria alterado, uma vez que no estamos tratando dos casos de uso, mas sim dos smbolos do LEL, seus cenrios e aspectos relacionados. A seguir veremos como est a ferramenta Requisite aps a alterao efetuada por Wiese (2006) e ainda sem as alteraes de acordo com a DAORE. 6.1.1 O Menu Principal da Requisite Seu Menu Principal apresenta as opes verificadas na figura 6.1 e na Opo File podemos observar que possui um sub-menu, que oferece as opes de: New Especifica um novo projeto, por isso, talvez a opo possa ser renomeada para Project, ao invs de File. Open Recent especifica os projetos recentes que foram abertos. Esta opo no pode ser verificada pois no est operacional. Open esta opo s funciona se o usurio abrir um novo projeto, fecha-lo e logo depois tentar abrir, sem fechar a ferramenta, seno ela no consegue abrir o projeto. Save salva um projeto aberto que j foi salvo. Save as salvar como, para um projeto aberto esta opo permite a escolha do nome do projeto e a pasta de localizao. Open from DiSEN busca um arquivo .XMI no pode ser testado, uma vez que no possua um arquivo XMI do projeto DiSEN (foco do trabalho de Wiese).
1 2
Disponvel para download em: http://www.gentleware.com/. Disponvel para download em: http://www.sparxsystems.com/
160
Save to DiSEN salva um arquivo no formato .XMI. Ele cria o arquivo especificado, porm no pode ser testado (foco do trabalho de Wiese).
Close Fecha o projeto aberto. Exit Sair da ferramenta.
FIGURA 6.1 MENU PRINCIPAL DA FERRAMENTA R EQUISITE.
As opes Edit, Diagrams e Windows, no esto operacionais sem instanciao de projeto ou a criao de um novo. A opo Help oferece apenas uma tela sobre informaes gerais do sistema. Os botes localizados no lado esquerdo e acima so botes rpidos para acessar determinadas tarefas, os botes e permitem que se selecionados, ao incluirmos
uma associao entre os casos de uso, estas sero identificadas com o estereotipo <<exclusive>> ou <<include>>. A figura 6.2 apresenta o NetBeans3 e a ferramenta Requisite e seu cdigo a ser analisado.
Disponvel em: http://www.netbeans.org/ . ltimo acesso em: 22/11/06.
161
FIGURA 6.2 NETB EANS E A FERRAMENTA R EQUISITE.
6 .2 Im ple me nta ndo a D AO RE

Cada vez mais os projetos desenvolvidos requisitam um maior uso de recursos e at mesmo novas tcnicas que permitam que acompanhem e usem a evoluo natural da tecnologia. Isto se aplica tambm aos processos de desenvolvimento. Deste modo, podemos prever que a incluso de aspectos candidatos nos projetos desenvolvidos no ambiente DiSEN permitem acrescentar novas caractersticas que podem ser tratadas desde o inicio do desenvolvimento. Assim, podemos afirmar que futuros projetos se beneficiaro com a implantao das caractersticas providas pela DAORE.
6 .2 .1 P ro je to D iSE N
O projeto DiSEN possui como objetivo principal prover um ambiente de desenvolvimento de software distribudo. Isto implica no uso integrado de vrias ferramentas de desenvolvimento, sejam elas na forma de plugins ou stand-alone. Assim, a exportao de dados, sejam eles no formato XML ou atravs de transformaes 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 customizao ou adaptao para as ferramentas utilizadas pela equipe de desenvolvimento.
162
Deste modo, o projeto DiSEN pode ser beneficiado com a implementao na fase de requisitos de uma abordagem que permita e padronize os documentos a serem gerados, alm de possibilitar a identificao dos aspectos candidatos do projeto.
6 .2 .2 A No v a F e rra me nta Re quis ite

A modelagem dos diagramas referentes n ova verso 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 R EQUISITE
Disponvel em: http://www.borland.com/br/products/together/index.html . Ultimo acesso em: 22/11/06.
163
Gerar recursos
<<include>> Construir Cenarios Construir Lexico
<<include>> Gerar ator
<<include>> gerar cenarios Construir use case
Gerar Aspectos Criar Projeto
Gerar Ontologias Engenheiro de Requisitos <<extend>> Construir hierarquia Exportar XML Cosntruir RO Construir RNF
FIGURA 6.4 DIAGRAMA DE CASOS DE USO DA NOVA REQUISITE
Observando a figura 6.4 podemos concluir que a nova verso da ferramenta Requisite possui algumas funcionalidades que no existiam na verso anterior (para uma comparao entre os casos de uso, verifique o captulo 2, onde est detalhada a ferramenta requisite). Estas funcionalidades, previstas na abordagem DAORE permitem que a ferramenta construa requisitos no funcionais, requisitos organizacionais, gere os elementos dos cenrios a partir dos smbolos do LEL, gere aspectos e construa a ontologia do projeto. Assim, podemos verificar que alm das funcionalidades j existentes na verso anterior teremos: a) Construir RNF permite que se crie, modifique, consulte e remova os requisitos no funcionais primrios e secundrios, bem como as suas estratgias de satisfao; b) C onstruir 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 smbolos do LEL, cenrios, ontologias e aspectos candidatos;
164
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 smbolos 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.
165
FIGURA 6.5 DIAGRAMA DE CLASSES PROPOSTO DA NOVA VERSO DA REQUISITE
166
O diagrama de classes apresentado na figura 6.5 apresenta as seguintes caractersticas adicionais: Identificao do smbolo do LEL, como subject, verb, object ou state; Associao do Behavioral Response com requisitos no funcionais, funcionais e organizacionais, alm de poder ser introduzido instrues OCL; Associao dos cenrios ao smbolo do LEL identificado como verbo; Associao dos smbolos do LEL com os termos da ontologia; Gerao de aspectos candidatos automaticamente a partir dos RNF includos no projeto atravs do Behavioral Response; e Exportao de arquivos no padro XML atravs de XML Schemas definidos. Deste modo, algumas mudanas 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 necessrio 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 opes abordadas na abordagem DAORE, como podemos observar na figura 6.7.
167
FIGURA 6.7 NOVO MENU PRINCIPAL DA FERRAMENTA R EQUISITE.
Podemos observar que a figura 6.7 apresenta como opes principais: Project, LEL, Restrictions, Use Case, Ontology e Help. A opo Project o antigo File e apresenta o sub-Menu da figura 6.8
FIGURA 6.8 S UB-MENU DE PROJECT.
168
Agora, como estamos nos conectando com o banco POSTGRESQL, algumas opes foram excludas, para a incorporao de outras. Assim, a opo 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 ao que deve ser realizada. A inteno de que tenhamos um pequeno help de ajuda ao usurio. Assim, como neste campo, todos os campos inseridos tem essa caracterstica, bem como os botes inseridos. XML FILES - onde podemos gerar o arquivo XML de acordo com os XML Schemas criados para o LEL, Cenrios, Aspectos e Ontologias; Aspects Permite que se gere os aspectos, atualize e gere os conflitos do projeto selecionado; Exit Sair da ferramenta. A opo do Menu Principal LEL, apresenta as opes de acordo com a figura 6.10.
169
FIGURA 6.10 S UB-MENU DA OPO LEL
Uma das maiores mudanas efetuadas na ferramenta diz respeito a tela principal do LEL (a opo do sub- menu New/Update). Agora, podemos inserir a caracterstica principal do lxico, ou seja, qual o seu tipo. A partir da podemos realizar uma srie de procedimentos atravs da ferramenta de forma automtica, como: gerao de atores, recursos e cenrios, o que facilita o processo de construo do LEL. Esta tela est de acordo com a interface da figura 6.11.
170
FIGURA 6.11 NEW/UPDATE LEL
Assim, em cenrios poderamos ter especificado o tipo MDSODI, conforme na ferramenta CALEL. No Menu principal Restrictions podemos editar os RNF e RO. Estes seriam inseridos em cenrios, conforme a CALEL. No Menu Principal Use Case seria includo as opes do Wiese (de importao e exportao do modelo XMI) e a elaborao dos diagramas de casos de uso, de acordo com a figura 6.12.
171
FIGURA 6.12 S UB-MENU USE CASE
Na seqncia, h a gerao de ontologias conforme foi elaborado com a CALEL. As alteraes efetuadas foram realizadas utilizando o NetBeans, conforme a verso alterada por Wiese. A escolha do POSTGRESQL como banco de dados para a persistncia est de acordo com o que est sendo feito no projeto DISEN.
6 .2 .3 An lise do Im pa c to da s Muda n a s
As mudanas sugeridas na ferramenta Requisite permitem que a abordagem DAORE seja includa no seu processo sem afetar o trabalho que j estava sendo realizado. Na verdade, houve um acrscimo de informaes a serem adicionadas. Estas informaes dizem respeito s funcionalidades do projeto a ser desenvolvido, logo, adicionam uma maior clareza na definio dos requisitos a serem mapeados.
172
Porm, precisa-se analisar o impacto de uma mudana efetuada na ferramenta Requisite e no projeto DiSEN a fim de se avaliar se a mudana no ser uma quebra de paradigma. Para isso precisamos identificar pontos a serem analisados e comparados com as diferentes verses da Requisite, a anterior e a atual. Deste modo, a fim de definir parmetros de comparao para avaliar as duas ferramentas, iremos utilizar a NBR 13596 - Tecnologia de Informao: Avaliao de Produto de Software (ISO 9126) e utilizada no captulo 2 para realizar a comparao entre as abordagens de desenvolvimento. Ao levarmos em conta o Requisite na sua verso 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 VERSES DA REQUISITE
Caracterstica
FUNCIONALIDADE
Requisite Original - Faltava persistncia Adequao - Identificao dos RNF e RO Faltava Acurcia identificao dos termos do LEL A partir do trabalho de Wiese (2006) possui exportao e Interoperabilidade importao de arquivos XMI para casos de uso Faltava identificar os smbolos do LEL Conformidade No implementado
Sub-caracterstica
Novo Requisite Atendida
Atendida
Segurana de acesso Maturidade Tolerncia a falhas Recuperabilidade Inteligibilidade Apreensibilidade Operacionalidade Comportamento em relao ao
Foi acrescida de exportao de arquivos XML seguindo um padro definido no XML Schema De acordo com as especificaes de Leite (1997) para o LEL Atravs de identificao por senha Aplicado no banco de dados definido Help de auxilio disponvel (hint) Bom tempo de resposta entre as
CONFIABILIDADE
No aplicvel No implementado
USABILIDADE EFICINCIA
Dificultada pela ausncia de help Bom tempo de resposta entre as
6. A Ferramenta Requisite e a Abordagem DAORE tempo Comportamento em relao aos recursos Continuao da Tabela 6.1 Caracterstica Sub-caracterstica Adaptabilidade Capacidade para ser instalado PORTABILIDADE Capacidade para substituir Analisabilidade Modificabilidade MANUTENIBILIDADE Estabilidade operaes e recursos utilizados
173 operaes e recursos utilizados (Banco de dados)
Requisite Original Desenvolvido em Java imediata circularidade Java No possui BD
Novo Requisite Desenvolvido em Java imediata circularidade Java Atravs de mecanismos de BD
Ao observarmos a tabela 6.1 podemos verificar que a maturidade n o aplicada na anlise, pois este item deve ser levado em conta quando do uso constante em diversos projetos, com algum tempo de uso da ferramenta. Algumas consideraes so necessrias para as caractersticas e analise efetuada na tabela 6.1: Adequao em sua primeira verso a ferramenta Requisite no trata dos requisitos no funcionais e organizacionais, sendo assim, deixa de considerar aspectos importantes no projeto a ser desenvolvido, alm disso, a persistncia no est sendo feita de forma adequada, conforme foi visto no inicio deste captulo. Com a modificao proposta, a nova verso do Requisite ir suportar os RNF e organizacionais, alm de possuir integrao com um banco de dados. Acurcia A verso inicial da Requisite no faz identificao dos termos definidos no LEL, dificultando a gerao automtica de alguns elementos usados na especificao de cenrios, como os atores e recursos, alm da prpria identificao do cenrio. Deste modo, a gerao de resultados satisfatrios ou corretos em relao aos termos do LEL est comprometida. Interoperabilidade com o trabalho de Wiese (2006) podemos exportar e importar documentos XMI do projeto, porm apenas em relao aos casos de uso especificados. Com a mudana proposta, a ferramenta
174
Requisite passaria a incluir a exportao de documentos XML em padres especificados atravs de XML Schema do LEL, cenrios, aspectos e ontologias. Conformidade a ferramenta Requisite identifica os termos do LEL e a partir destes, deveria facilitar a identificao e descrio dos cenrios, conforme previsto por Leite (1997). Porm, como no h a identificao dos termos do LEL (o seu tipo) no podemos gerar de forma automtica os atores, recursos e os prprios cenrios. Assim, inicialmente no est de acordo com o que se prev no LEL. Com a mudana proposta, a identificao dos termos do LEL o primeiro passo para a gerao automtica dos cenrios. Segurana de Acesso Inicialmente a ferramenta Requisite est implementada de forma no integrada ao ambiente DiSEN e sendo assim precisa ter restries de uso quanto ao projeto e usurios qualificados. A nova verso da Requisite deve ser capaz de gerenciar e tratar acessos indevidos, podendo ser atravs de senha de acesso. Tolerncia a falhas e Recuperabilidade geralmente este item est ligado ao tratamento em relao aos seus dados, porm na primeira vers o d a Requisite no h persistncia e, deste modo, no existe tratamento de rollback. A nova verso da Requisite deve possuir
tratamento com banco de dados, e o prprio mecanismo prev tratamentos de backup e recover dos mesmos (dependendo da verso do banco de dados). Inteligibilidade, apreensibilidade e operacionalidade a ausncia de help on line para determinadas tarefas um ponto crucial para uma aprendizagem mais rpida, alm de facilitar a operacionalidade e inteligibilidade de uma ferramenta. Em sua primeira verso, a Requisite no possui help online, sendo mais uma caracterstica a ser acrescentada na nova verso. Comportamento em relao ao tempo e aos recursos de um modo geral a ferramenta, na primeira verso, apresenta um bom tempo de
175
resposta, sendo igualmente um fator a ser passado para a prxima verso. Adaptabilidade e capacidade para ser instalada desenvolvida em Java, pode ser instalada no Windows ou Linux, no possuindo restries. Capacidade para substituir Utilizando o LEL para auxiliar a definir os cenrios podemos substituir de forma imediata outra qualquer. Tanto na verso anterior quanto na proposta, devemos manter os conceitos bsicos do LEL, a fim de possibilitar uma transio no traumtica entre ferramentas de desenvolvimento. Analisabilidade a analisabilidade do projeto pode ser feita atravs dos seus termos pelo princpio da circularidade. Modificabilidade as duas verses podem ser alteradas utilizando padro java, porm sem termos um impacto maior no projeto DiSEN. Estabilidade a primeira verso da ferramenta no possui implementao em banco de dados e portanto, no possui a estabilidade que um banco de dados pode oferecer. A nova verso possui integrao com um banco de dados, oferecendo uma estabilidade maior de suas informaes.
O impacto no projeto DiSEN seria principalmente no que diz respeito a identificao dos aspectos candidatos do projeto a ser desenvolvido. Pois estes aspectos iro influir nos passos definidos nos cenrios.
176
Neste captulo procurou-se identificar as principais mudanas a serem elaboradas na ferramenta Requisite para que integrasse a abordagem DAORE e o impacto destas mudanas no projeto DiSEN. A preocupao maior foi de que o impacto fosse o menor possvel, uma vez que se refletiria no projeto DiSEN como um todo. Assim, foi verificado que as incluses necessrias para a execuo das mudanas no afetou de forma desastrosa, pois a prpria ferramenta Requisite funciona ainda como uma ferramenta stand-alone em relao ao projeto DiSEN, sendo um projeto futuro a implementao da mesma como u m plug-in (WIESE, 2006). Assim, a possibilidade de gerar aspectos candidatos atravs do LEL do projeto altamente vivel a partir das mudanas propostas. Com isso, as prximas fases do processo de desenvolvimento podem usufruir das facilidades oferecidas pela aplicao direta dos aspectos candidatos j elicitados, podendo inclusive ser alvo de futuros estudos a extenso da abordagem para as outras fases do desenvolvimento.
7.Concluso
177
CAPTULO
7
CONCLUSO
Termos conscincia de que somos ignorantes um grande passo rumo ao saber. Disraeli
Es te c ap tulo apres enta de ma ne ira s int t ic a as c ontribui es da noss a abordagem. Depois , s ugerimos alguns tpic os para traba lhos futuros , bas eando-nos nas limita es da abordagem propos ta. Por fim, apres entamos noss as c ons idera es fina is .
7 .1 Co nt ribui e s
Henry Ford, o genial construtor de automveis norte-americano ficou famoso (entre outras coisas) por que aplicou um sistema de produo chamado 'em srie' para a fabricao de automveis. Muitos pensam que Ford descobriu algo novo e revolucionrio, mas fcil perceber que ele apenas implementou algo que a natureza vem fazendo desde que a vida surgiu no planeta terra, milhares de milhes de anos atrs. Neste processo, cada operrio da fbrica somente se dedica a realizar uma nica tarefa, bem acabada, no menor tempo possvel, dentro de uma chamada 'linha de montagem'. Como resultado, a fbrica como um todo sai ganhando em tempo, qualidade e preo dos seus produtos. Isto fez de Ford um dos homens mais ricos do seu tempo. Se cada operrio da fbrica construsse o carro completo desde o inicio at o final, demoraria muitas vezes mais, teria uma qualidade provavelmente inferior, e seria enormemente caro.
7.Concluso
178
Fazendo uma analogia com a engenharia de software tem-se com o conceito (tambm antigo) do famoso dividir para conquistar. Com origens em tcnicas de construo de algoritmos, permitia que se tivesse a preocupao de lidar com um problema por vez. Assim, pode-se observar que a separao de propriedades no uma tcnica recente, mesmo porque, ao construirmos um projeto de software aplicamos naturalmente a separao de propriedades, independente da abordagem utilizada. Kiczales et al. (1997) apresentou vrios pontos em que a pesquisa na separao de propriedades poderia avanar, entre eles esto: (i) Como antecipar a modelagem de aspectos para as atividades de anlise e projeto; e (ii) Como integrar a orientao a aspectos com mtodos, ferramentas e processos de desenvolvimento existentes. Esta dissertao oferece contribuies nessas duas direes apontadas acima. Primeiro, porque a abordagem proposta permite antecipar a identificao de aspectos candidatos na fase de requisitos e segundo porque permite integrar esta identificao com um processo ou tcnica existente, como o LEL. Alm disso, aborda outras questes j existentes, como as de Cysneiros (2002) e Breitman (2003) (2005), permitindo, inclusive, a explorao de uma nova faceta ligada ontologias para a Web Semntica, de acordo com a proposta apresentada por Breitman (2005).
7 .2 L im ita e s e Tra ba lho s F ut uro s

Esta dissertao trata do desenvolvimento de software orientado a aspectos na atividade de requisitos, mas sua principal limitao est condicionada a no anlise de como seria a transio para a fase de projeto e implementao do sistema. Assim, podemos listar algumas perspectivas de trabalho futuras: Estender a abordagem DAORE para as outras fases do
desenvolvimento, especificando a transio entre as fases e seus artefatos.
7.Concluso
179 Processo de Datamining na fase de requisitos com a utilizao de Ontologias. Implementar uma ferramenta integrada ao DiSEN (plug in) para suporte a DAORE. Realizao de mais estudos de caso nas abordagens existentes, a fim de fornecer mais heursticas e diretrizes para os desenvolvedores. Elaborao de anlise sobre o impacto das adaptaes realizadas em relao a questes arquiteturais e em relao iteratividade e incrementalidade do Processo Unificado em relao a orientao a aspectos. Construo de ferramenta que possa gerar automaticamente, a partir das tabelas de composio e cenrios do LEL, a perspectiva de especificaes de casos de uso e diagramas de interao com a presena de aspectos que afetam esses artefatos; e Avaliao do LEL e s u a possvel integrao com a Model Driven Architecture - MDA (MDA, 2003) como proposta de m elhoria das especificaes do projeto e aumento de reuso dos componentes.
7 .3 Co ns ide ra e s F ina is
Conforme apresentado no Captulo 4, o objetivo inicialmente proposto foi o de estabelecer uma abordagem simples para possibilitar a identificao dos aspectos candidatos na fase de requisitos do ciclo de desenvolvimento. Este objetivo foi alcanado por meio da insero dos fundamento s d o paradigma orientado a aspectos na integrao do LEL, mas sem ocasionar tanto impacto em como o processo conduzido, j que as alteraes concentram-se mais na contextualizao dos cenrios no LEL. Alm disso, pelo fato das adaptaes no se prenderem aos mecanismos de uma linguagem orientada a aspectos especfica e sim aos conceitos fundamentais do paradigma orientado a aspectos, a abordagem DAORE oferece suporte tanto a uma
7.Concluso
180
implementao orientada a aspectos (lidando com os aspectos candidatos) como a uma implementao tradicional (cenrios no LEL). Outra caracterstica positiva da abordagem DAORE que as adaptaes seguem um raciocnio lgico a partir da especificao dos requisitos. Especificando-os primeiramente e ao longo do desenvolvimento do processo e incluindo aspectos relacionados implementao de RNF e RO aps a identificao dos smbolos existentes nos RF. A implementao dos aspectos atravs de tabelas de composio, permite separar as preocupaes transversais nos cenrios aos quais ela se apresenta, garantindo que estas preocupaes aspectuais tenham uma definio clara de quando e como ser implementada. Pelo fato de possibilitar a separao das propriedades transversais, os artefatos que obtidos a partir da experimentao realizada possuem um melhor potencial de reuso, manuteno e compreenso, 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 so 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.
7 .4 Tra ba lho s Subme t ido s

Durante a elaborao desta dissertao muitas idias e solues foram apresentadas. Por conseqncia 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 - Qubec, Canad. Realizado no perodo de 25 a 27 de outubro de 2006. Ttulo: Comparing Approaches in AORE through ISO/IEC 9126. Condio: Aceito. 2. RITA - Revista de Informtica Terica e Aplicada. Ttulo: Comparing Approaches in AORE through ISO/IEC 9126.
7.Concluso
181
3. SBES - 21th Brazilian Symposium on Software Engineering 2007. Ttulo: AORE in a Distributed Environment: The DAORE Approach 4. XXIII Conferncia LatinoAmericana de Informtica - 9-12 Octubre - San Jos Costa Rica
Referencias Bibliogrficas
182
Referncias Bibliogrficas
S til o conhecimento que nos torna melhores. Scrates
Nes ta parte apres entamos as refernc ias bibliogrf ic as c ons ultadas para a elabora o da dis s erta o.
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. Disponvel 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. ; Tekinerdoan, 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 Definio de Requisitos da MDSODI no contexto do ambiente DiSEN. 2002. Dissertao de mestrado 83p Departamento de Informtica - 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.
183
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-7576BREITMAN, 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:214221. 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 Arajo ,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. ARAJO, 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 Ingeniera 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 Maro 2004. BOOCH, G.; RUMBAUGH, J . , JACOBSON, I . The Unified Modeling Language , AddisonWesley,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, Siobhn; BANIASSAD, Elisa. Aspect-Oriented Analysis and Design the theme approach. United States. AddisonWesley, March, 2005.
184
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):3338, 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 Estratgia de Suporte Engenharia de requisitos. MI Congresso da Sociedade Brasileira de Computao, 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 distribudos. Trabalho de graduao Departamento de informtica 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. Construccin de Escenarios a partir del Lxico Extendido del Lenguage JAIIO'97, Buenos Aires, 1997, pp. 65-77. Haumer, P e t e r ; 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 Distribudos Inteligentes. Projeto de Pesquisa. Universidade Estadual de Maring, Departamento de Informtica. 1999
185
IEEE. Qualities of a good software requirements specification ( S R S ) . Verso traduzida disponivel em: www.ieee.org e http://www.unoeste.br/fipp/estagio/arquivos/IEEE-Std-8301998_traducao.pdf . Acesso em 13/01/2006. ISO, International Standard ISO/IEC 9126: Software Engineering - Product Quality. Disponvel 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 discurso sobre orientao a aspectos. Disponvel 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 OOPSLA1999. 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): 184198 (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 no funcionais aos requisitos baseados em aes concertas , Dissertao de mestrado, Departamento de informtica, 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 . Anlise Essencial de Sistemas , Makron Books, So Paulo,1984.
186
MDA G u i d e . Disponvel 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.; Arajo, 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 Repositrio de Metadados para Ambiente de Desenvolvimento de Software Distribudo. Maring: DINUEM/ UFPR, 2002. Dissertao 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 distribudo baseada em agentes. Dissertao de mestrado Programa de Ps-Graduao em Cincia da Computao, Instituto de Informtica, Universidade Federal do Rio Grande do Sul. Porto Alegre: 2002 PEDRAS, M. E. V. Uma Ferramenta de Apoio ao Gerenciamento de Desenvolvimento de Software Distribudo. Maring: DINUEM/ UFPR, 2002. Dissertao de Mestrado. PRESSMAN, R. Software Engineering: a Practitioners 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 .; ARAJO, 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, Maro 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
187
SILVA, L. de P. Uma proposta de evoluo em sistemas legados. Monografia - Especializao, Curso de Ps-Graduao em Sistemas de Informao Distribudos, UNIOESTE, 2004. SILVA, Lyrene; Leite, Julio C. Sampaio. Integrao de caractersticas transversais durante a modelagem de requisitos. 19 Simposio Brasileiro de Engenharia de Software. Minas Gerais, 2005. SHLAER, S.; MELLOR, S. Anlise de Sistemas Orientada para Objetos, Makron Books, So 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. Dissertao de Mestrado, UFPE, 2004. SOUZA, Michel. Metadados. Disponvel 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. I n Proceedings of the 21st International Conference on Software Engineering (ICSE'99), 107119, May 1999. Los Angeles, California, United States. TEKINERDOAN, B e d i r : ASAAM: Aspectual Software Architecture Analysis Method. WICSA 2004: 5-14 THEME. Conceitos Gerais sobre a Abordagem Theme e ferramenta Theme/Doc Disponvel 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 Informtica, Universidade Federal de Pernambuco, Tese de Doutorado, Dezembro, (2002). TRAVASSOS, G. H. Introduo a Engenharia de Software Experimental. Relatrio tcnico. Programa de Engenharia de Sistemas e Computao. COPPE/UFRJ, 2002. UML - Unified Modeling Language, version 2.0. The Object Management Group. Disponvel em: http://www.uml.org/. Ultimo acesso: 26/09/2006. XML SCHEMA. Disponvel 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.
188
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. Anlise e projeto de sistemas de informao orientados a objetos. So Paulo. Elsevier, 2004 W3C. Web-Ontology (WebOnt) Working Group . Documentos diversos sobre Ontologias. Disponvel em: http://www.w3.org/2001/sw/WebOnt/. Ultimo acesso: 04/11/06.
Anexo A
189
ANEXO
A
SCHEMAS XML GERADOS
A se g uir a pre se nta mo s o s Sc he ma s X ML g e ra do s pa ra o no sso t ra ba lho . P rime ira me nte a pre se nta mo s a v is ua liza o g r fic a e de po is o a rquiv o te xto . Os Sc he ma s X ML fo ra m e la bo ra do s a t ra v s da fe rra me nta Sty lus St udio 2 .
Anexo A
190
Asp ecto s LE L.x sd
?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>
LE LSi mbo lo s. xs d
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
LE LC en ario s. xs d
<?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 <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>
195
Anexo A </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>
196
Onto lo gia .x sd
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>
Onto hi erar qu ia .x sd
<?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
Anexo A <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>
198
Anexo B
199
ANEXO
B
TELAS DO OORNF
A se g uir a pre se nta mo s a s te la s do s iste ma O OR NF e m s ua no v a v e rs o a lte ra da , que fo i c ha ma da de C ALEL , c o m o e st udo de c a so a pre se nta do no Ca pt ulo 5 .
Anexo B A seguir temos a tela do Menu principal da ferramenta CALEL:
200
Como podemos observar, nem todos os itens do Menu Principal estaro acessveis em um primeiro momento, pois devemos escolher um projeto para podermos inserir os smbolos do LEL, entre outras opes. Porm, podemos acessar a tela dos RNF, onde podemos realizar as operaes bsicas nos Requisitos no funcionais (tela a seguir).
Anexo B
201
Primeiramente escolhemos/inclumos o nome do projeto:
A seguir vemos um exemplo do LEL, aqui tnhamos apenas alguns termos includos, e podemos observar que os termos que aparecem sublinhados so aqueles inclusos no projeto. medida que inserimos novos smbolos este principio (de circularidade) se torna mais evidente.
Aps a insero de todos os smbolos, podemos tratar dos cenrios. Para isto, podemos gerar os atores de forma automtica, bem como os recursos. A seguir veremos as telas correspondentes.
Anexo B
202
Vale observar que todos os atores sero includos como sendo primrios. A situao ser alterada aps a insero dos atores nos cenrios. Para a nomenclatura MDSODI ser de acordo com o cenrio tratado.
Anexo B
203
Anexo B
204
Aps a gerao automtica dos atores e recursos, podemos gerar tambm os cenrios. Alguns campos no sero preenchidos de forma automtica, devendo existir a interveno do operador. Para isso, ao acessar a tela de cenrios Update/View, podemos alterar o cenrio e, inclusive incluir novos cenrios.
Na tela anterior, ao inserirmos os episdios podemos inserir restries e sentenas prprogramadas (condicionais e opcionais) tecla do boto direito no mouse.
Anexo B
205
A seguir podemos observar a incluso de uma restrio OCL:
Aps os episdios inseridos com suas respectivas restries podemos gerar os aspectos candidatos, mostrado no exemplo a seguir.
Anexo B
206
Anexo B
207
A seguir mostraremos a tela para atualizao dos aspectos e suas regras de composio.
Anexo B
208
Como podemos observar ele j ir trazer os aspectos relativos aos requisitos no funcionais, observe o campo ORIGIN indicando RNF. Ao clicarmos nos cenrios afetados obtemos a opo de atualizarmos os cenrios afetados pelo aspecto selecionado. Observe a tela abaixo:
Anexo B
209
Como podemos observar alguns campos no so preenchido pela gerao automtica dos aspectos, estes campos devem ser atualizados para que possamos depois gerar a tabela de conflitos. Se quisermos adicionar um cenrio basta clicar no boto insert e ele ir mostrar todos os cenrios do projeto, como mostra a tela abaixo:
Anexo B Depois basta clicarmos em Select and Insert, para que o cenrio seja includo como cenrio afetado.
210
A tela acima representa a verificao de conflitos entre os aspectos , de acordo com o especificado no projeto. A resoluo destes conflitos tpica 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
Aps 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 pgina 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), esto no anexo C.
Anexo C
215
ANEXO
C
ARQUIVOS XML GERADOS NO ESTUDO DE C ASO
A se g uir a pre se nta mo s o s a rquiv o s X ML g e ra do s a t ra v s do s X ML Sc he ma pro po sto s c o m o e studo de c a so a pre se nta do no Ca pt ulo 5 .
Anexo C
216
Asp ecto s .x ml
<?xml version="1.0"?> <Aspectos xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/Aspectos LEL.xsd"> <Projeto id="-9223372036854775808" nome="string">   </Projeto> <aspecto_candidato> <id>1</id> <nome> Confidenciabilidade </nome> <origem>RNF</origem> <descricao> Garantir a autenticao e validao do usuario </descricao>  <cenariosafetados> <cenarioid>1</cenarioid> <nome_cenario>A ltera r p artic ip an te </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro) </informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 2</cenarioid> <nome_cenario> Exc lu ir p art icip an te </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 3</cenarioid> <nome_cenario> Co n s u ltar p articip an tes </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 4</cenarioid> <nome_cenario>- Cad as trar ev en to </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais>
Anexo C </cenariosafetados> <cenariosafetados> <cenarioid> CN # 5</cenarioid> <nome_cenario> Cad as trar co mis s o </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 6</cenarioid> <nome_cenario> Cad as trar co mit </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 7</cenarioid> <nome_cenario> Receb er recu rs o s </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 8</cenarioid> <nome_cenario> Dis trib u ir recu rs o s </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 9</cenarioid> <nome_cenario> Pag ar fo rn eced o r </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 10</cenarioid> <nome_cenario> Receb er p ag a men to </nome_cenario> <condicao> </condicao>
217
Anexo C <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 12</cenarioid> <nome_cenario>- In s crev er-s e em ev en to </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 13</cenarioid> <nome_cenario> En v ia r trab alh o </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 14</cenarioid> <nome_cenario> Efetu ar p ag amen to </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 15</cenarioid> <nome_cenario> En v ia r p ales tra </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 16</cenarioid> <nome_cenario> Cad as trar p arceiro s </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> CN # 1 7</cenarioid>
218
Anexo C <nome_cenario> En v ia r mater ia l </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 18</cenarioid> <nome_cenario> Emit ir ce rtificad o s </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 19</cenarioid> <nome_cenario> A tu aliza r p ro g ra mao </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> CN # 2 0</cenarioid> <nome_cenario> Se lec io n ar trab alh o </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 21</cenarioid> <nome_cenario> Fo rn ecer recu rs o s </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 22</cenarioid> <nome_cenario>Se lecio n ar min is tran te</nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe
219
Anexo C
(msgErro)</informacoesadicionais>
220
</cenariosafetados> <cenariosafetados> <cenarioid> 23</cenarioid> <nome_cenario> Se lec io n ar p ales tran te </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 24</cenarioid> <nome_cenario> Emit ir c rach s </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 25</cenarioid> <nome_cenario>- En v iar req u is io </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> </aspecto_candidato> <!Novo aspecto--> <aspecto_candidato> <id>2</id> <nome> Integridade </nome> <origem>RNF</origem> <descricao> Garantir a atualizao atravs de pessoal autorizado e validado </descricao>  <cenariosafetados> <cenarioid> 1</cenarioid> <nome_cenario>A ltera r p artic ip an te </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro) </informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 2</cenarioid> <nome_cenario> Exc lu ir p art icip an te </nome_cenario>
Anexo C <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 2</cenarioid> <nome_cenario> Exc lu ir p art icip an te </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 4</cenarioid> <nome_cenario>- Cad as trar ev en to </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 5</cenarioid> <nome_cenario> Cad as trar co mis s o </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 6</cenarioid> <nome_cenario> Cad as trar co mit </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 7</cenarioid> <nome_cenario> Receb er recu rs o s </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais>
221
Anexo C </cenariosafetados> <cenariosafetados> <cenarioid> 8</cenarioid> <nome_cenario> Dis trib u ir recu rs o s </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 9</cenarioid> <nome_cenario> Pag ar fo rn eced o r </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 10</cenarioid> <nome_cenario> Receb er p ag a men to </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 12</cenarioid> <nome_cenario>- In s crev er-s e em ev en to </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 13</cenarioid> <nome_cenario> En v ia r trab alh o </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 14</cenarioid> <nome_cenario> Efetu ar p ag amen to </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao>
222
Anexo C <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 15</cenarioid> <nome_cenario> En v ia r p ales tra </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> CN # 1 6</cenarioid> <nome_cenario> Cad as trar p arceiro s </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 17</cenarioid> <nome_cenario> En v ia r mater ia l </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 18</cenarioid> <nome_cenario> Emit ir ce rtificad o s </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 19</cenarioid> <nome_cenario> A tu aliza r p ro g ra mao </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid>2 0</cenarioid>
223
Anexo C <nome_cenario> Se lec io n ar trab alh o </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 21</cenarioid> <nome_cenario> Fo rn ecer recu rs o s </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> CN # 2 2</cenarioid> <nome_cenario>Se lecio n ar min is tran te</nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 23</cenarioid> <nome_cenario> Se lec io n ar p ales tran te </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 24</cenarioid> <nome_cenario> Emit ir c rach s </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro)</informacoesadicionais> </cenariosafetados> <cenariosafetados> <cenarioid> 25</cenarioid> <nome_cenario>- En v iar req u is io </nome_cenario> <condicao> </condicao> <regracomposicao>wrap</regracomposicao> <pontojuncao>1</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe
224
Anexo C
(msgErro)</informacoesadicionais>
225
</cenariosafetados> </aspecto_candidato> <!novo aspecto--> <aspecto_candidato> <id>3</id> <nome> CPF_Cliente </nome> <origem>RF</origem> <descricao> Verificar se o cliente esta com obrigaes em dia </descricao>  <cenariosafetados> <cenarioid> 12</cenarioid> <nome_cenario> Ins creve r-se em eve nto </nome_cenario> <condicao> </condicao> <regracomposicao> wrap </regracomposicao> <pontojuncao>3</pontojuncao> <informacoesadicionais> Se situaoOK ento executa(ponto juno) Seno exibe (msgErro) </informacoesadicionais> </cenariosafetados> </aspecto_candidato> <!novo aspecto--> <aspecto_candidato> <id>4</id> <nome> Validar situaao </nome> <origem>RO</origem> <descricao> Verificar se cliente VIP </descricao>  <cenariosafetados> <cenarioid> 12</cenarioid> <nome_cenario> Ins creve r-se em eve nto </nome_cenario> <condicao> </condicao> <regracomposicao> overlap.after </regracomposicao> <pontojuncao>3</pontojuncao> <informacoesadicionais> Se executa(ponto juno) ento aplicardesconto() Seno verificar potencial() </informacoesadicionais> </cenariosafetados>  <cenariosafetados> <cenarioid>1 4</cenarioid> <nome_cenario> Efe tuar pag ame nto </nome_cenario> <condicao> </condicao> <regracomposicao> overlap.before </regracomposicao> <pontojuncao>3</pontojuncao> <informacoesadicionais> Se executa(ponto juno) ento aplicardesconto() Seno verificar potencial() </informacoesadicionais> </cenariosafetados> </aspecto_candidato> </Aspectos>
Anexo C
226
Sim bo lo s. xml
<?xml version="1.0"?> <Projeto xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/LELSimb olos.xsd"> <id_projeto>1</id_projeto> <dominio>comunicaao</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> cada stra r c lie nte </descricao_impacto> <id_impacto>2</id_impacto> <descricao_impacto> co ns ult a e ve nto s e m ab erto</descricao_impacto> <id_impacto>3</id_impacto> <descricao_impacto> co ns ulta e ve ntos fec hados</descricao_impacto> <id_impacto>4</id_impacto> <descricao_impacto> a lter ar par t ic ipa nte</descricao_impacto> <id_impacto>5</id_impacto> <descricao_impacto> e xc luir par t ic ipa nte</descricao_impacto> <id_impacto>6</id_impacto> <descricao_impacto> co ns ulta r part ic ip a ntes</descricao_impacto> <id_impacto>7</id_impacto> <descricao_impacto> cadas tra r e ve ntos</descricao_impacto> <id_impacto>8</id_impacto> <descricao_impacto> cadas trar co misso</descricao_impacto> <id_impacto>9</id_impacto> <descricao_impacto> cadas trar co mit</descricao_impacto> <id_impacto>10</id_impacto> <descricao_impacto> re ceber re c ursos</descricao_impacto> <id_impacto>11</id_impacto> <descricao_impacto> pa gar fo r necedor</descricao_impacto> <id_impacto>12</id_impacto> <descricao_impacto> d ist r ib uir re c ursos</descricao_impacto> <id_impacto>13</id_impacto> <descricao_impacto> recebe r pa ga me nto</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> Pessoa q ue par t ic ipa de um e ve nto co mo : o uvinte, aprese ntado r, pa le stra nte, minis tra nte </descricao_nocao> </nocoes> <impactos> <id_impacto>1</id_impacto> <descricao_impacto> co ns ult a e ve nto s e m abe rto </descricao_impacto> <id_impacto>2</id_impacto> <descricao_impacto> co ns ulta e ve ntos fec hado s </descricao_impacto> <id_impacto>3</id_impacto> <descricao_impacto> co ns ulta r pro gr a maao </descricao_impacto> </impactos> </LEL> <!Os outros Elementos do LEL foram suprimidos para que ficasse menor o arquivo--> </Projeto>
Anexo C
228
Cen ario s. xml

<?xml version="1.0"?> <Projeto xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/LELCena rio.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>Co ns ultar e ve ntos e m aber to</titulo> <objetivo>Proced ime nto p ara q ua ndo des eja- se co nhece r todos os e ve ntos q ue esto e m aber to</objetivo> <contexto> <texto>S iste ma e mit indo co ns ulta de e ve ntos e m aber to</texto> </contexto> <atores> <nome> secr etr ia </nome> <tipo_ator>primario</tipo_ator> </atores> <atores> <nome> par t ic ipa nte </nome> <tipo_ator>primario</tipo_ator> </atores> <atores> <nome> parce iros </nome> <tipo_ator>secundario</tipo_ator> </atores> <atores> <nome> c lie nte s inc luidos </nome> <tipo_ator>primario</tipo_ator> </atores> <atores> <nome> c lie nte s </nome> <tipo_ator>secundario</tipo_ator> </atores> <recursos> <descricao>evento</descricao> </recursos> <episodios> <texto> S iste ma e xibe e ve ntos e m aber to </texto> <RNFEspecifico> <texto></texto> <estrategia></estrategia> </RNFEspecifico> <ExpressaoOCL> <texto> </texto>
Anexo C </ExpressaoOCL> <Rorg> <texto></texto> <estrategia></estrategia> </Rorg> </episodios> </cenarios> <!Os outros elementos foram suprimidos --> </Projeto>
229
Anexo C
230
Onto lo gia .x ml
<?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> Artigos a serem apresentados em um evento </descricao> <restricao></restricao> <nome>comite</nome> <descricao> Grup o de pessoas selecionadas para selecionar os trabalhos apresentados no evento</descricao> <restricao></restricao> <nome>participante</nome> <descricao> P essoa que participa de um evento como : ou v inte, apresentador, palestrante, min istrante</descricao> <restricao></restricao> <nome>evento</nome> <descricao> Conferencia ou Workshop a ser gerenciado pela empresa. Cada evento possui um perodo de realizao </descricao> <restricao></restricao> <nome>cliente inscrito</nome> <descricao> P essoa que solicitou o cadastro e foi aprovada, recebendo o seu log in e senha </descricao> <restricao></restricao> <nome>programacao</nome> <descricao> Cronograma a ser cumprido d o evento. Contem as palestras, trabalhos e cursos a serem apresentados no evento </descricao> <restricao></restricao> <nome>comissao</nome> <descricao> : Grupo de pessoas selecionadas para gerenciar o evento </descricao> <restricao></restricao> <nome>ministrante</nome> <descricao> Cliente inscrito para ministrar curso </descricao> <restricao></restricao> <nome>material</nome> <descricao> O ma ter ia l re fere nte ao c urso a se r minis trado e m um e ve nto </descricao> <restricao></restricao> <nome>requisicao</nome> <descricao> Documento que contem referencias aos recursos materiais necessrios 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> Ide nt ific ao do par t ic ipa nte do e ve nto </descricao> <restricao></restricao> <nome>certificado</nome> <descricao> Comp ro va nte de p art ic ipa o do e ve nto </descricao> <restricao></restricao> <nome>patrocinador</nome> <descricao> Empresa que fornecem recursos financeiros para a realizao do evento </descricao> <restricao></restricao> <nome>recursos</nome> <descricao> So materiais necessrios para a realizao e elaborao do evento. </descricao> <restricao></restricao> <nome>pagamento</nome> <descricao> Comprovante de quitao com o evento</descricao> <restricao> Podem ser: financeiro, humano e material </restricao> <nome>ouvinte</nome> <descricao> Cliente inscrito para assistir aos cursos, palestras e apresentaes do evento </descricao> <restricao></restricao> <nome>cliente</nome> <descricao> : Pes soa q ue a inda no so lic ito u o cadas tro, ape nas c lie nte e m pot e nc ia l </descricao> <restricao></restricao> <nome>inscricao</nome> <descricao> Ide nt ific ao de um c lie nte q ua ndo des eja fa zer se u c adast ro </descricao> <restricao></restricao> <nome>secretaria</nome> <descricao> P essoa que auxilia no gerenciamento do evento </descricao> <restricao></restricao> <nome>fornecedor</nome> <descricao> Empresa que fornece recursos (materiais ou humanos) para a realizao do evento </descricao> <restricao></restricao> </classe> <nome> Aberto</nome> <descricao> so os eventos que possuem o perodo de realizao maior ou igual do que a data atual </descricao> <restricao> subClasseOf: tipo-evento </restricao> <nome> fechado</nome> <descricao> so os eventos que possuem o perodo de realizao menor do que a data
Anexo C atual </descricao> <restricao> subClasseOf: tipo-evento </restricao> <nome> Tipo-Evento</nome> <descricao> conjunto dos estados possveis em que o evento pode estar no momento.Partio 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> -excludo</nome> <nome> -distribudo </nome> </propriedade> <axioma> <descricao> Trabalho pode ser: full, short, poster </descricao> </axioma> </ontologias>
232
Anexo C
233
hier arqu i a. xml

<?xml version="1.0"?> <ontohierarquia xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/ontohiera rquia.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> apresentao </classefilho> <classefilho> requisio </classefilho> <nome> Grupo_trabalho</nome> <classefilho> secretria </classefilho> <classefilho> comit </classefilho> <classefilho> comisso </classefilho> <nome> Objetos_evento</nome> <classefilho> crach </classefilho> <classefilho> certificado </classefilho> <classefilho> programao </classefilho> </classepai> </ontohierarquia>

A Engenharia de Requisitos Orientada A Aspectos - A Abordagem DAORE (Luciana de Paiva Silva)

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

A Engenharia de Requisitos Orientada A Aspectos - A Abordagem DAORE (Luciana de Paiva Silva)

Enviado por

Direitos autorais:

Formatos disponíveis

LUCIANA DE PAIVA SILVA

A ENGENHARIA DE REQUISITOS ORIENTADA A ASPECTOS: A ABORDAGEM DAORE

Dados Internacionais de Catalogao-na-Publicao (CIP) Biblioteca Central do Campus de Cascavel - Unioeste

LUCIANA DE PAIVA SILVA

A ENGENHARIA DE REQUISITOS ORIENTADA A ASPECTOS: A ABORDAGEM DAORE

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

Porque para Deus nada impossvel.

118 119 147 153 154 155 155 156 156

84 86 94 98 100 104 105 106 107 108 110

117 117 119 120 128

CAPTULO 6 TABELA 6.1 MAPEAMENTO ENTRE AS VERSES DA REQUISITE.................................

REFERNCIAS BILBIOGRFICAS................................................................ ANEXOS............................................................................................................

1 .6 Esc o po da D isse rta o

1 .7 Me to do lo g ia de De se nv o lv ime nto da P e squisa

5 - Aplicao na nova Abordagem

FIGURA 1.1 ESTRUTURA DA PESQUISA SEGUIDA.

1 .8 O rg a niza o da D isse rta o

Captulo 7: apresenta as concluses, enumera as contribuies e prope trabalhos futuros.

2.Desenvolvimento de Software Orientado a Aspectos

2.Desenvolvimento de Software Orientado a Aspectos

2 .1 Co nc e ito s Ge ra is de De se nv o lv ime nto O rie nta do a As pe c to s (AOSD)

2.Desenvolvimento de Software Orientado a Aspectos

2 .1 .1 Co nc e ito de a spe c to s, c onc ern e cr oss cutting con ce rn

2.Desenvolvimento de Software Orientado a Aspectos

2.Desenvolvimento de Software Orientado a Aspectos

2.Desenvolvimento de Software Orientado a Aspectos

2.Desenvolvimento de Software Orientado a Aspectos

2.Desenvolvimento de Software Orientado a Aspectos

2.Desenvolvimento de Software Orientado a Aspectos

2.Desenvolvimento de Software Orientado a Aspectos

2.Desenvolvimento de Software Orientado a Aspectos

2 .1 .4 A P ro g ra ma o O rie nta da a A s pe c to s e a Ling ua g e m As pe c tJ

2.Desenvolvimento de Software Orientado a Aspectos

Componentes Classe Combinador de aspectos (weaver) Aspecto Aspectos Sistema

2.Desenvolvimento de Software Orientado a Aspectos

2.Desenvolvimento de Software Orientado a Aspectos

Atributos Mtodos Pointcuts ou pontos de corte Advices ou informaes Declaraes intertype

Parte comum a classes

Construtores especficos de AspectJ

2.Desenvolvimento de Software Orientado a Aspectos

2 .2 .1 A bo rda g e m V ie wpo int

2.Desenvolvimento de Software Orientado a Aspectos

Revisar especificaes de requisitos

Relacionar concerns e requisitos

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

2.Desenvolvimento de Software Orientado a Aspectos

Requisitos dos Stakeholders Propriedades R1 propriedades 1 propriedades 2 ... propriedades n X X R2 X .... Rn X X

2.Desenvolvimento de Software Orientado a Aspectos

Aspecto 1 Aspecto 2 ... Aspecto n Aspecto 1 Aspecto 2 ... Aspecto n + _

2.Desenvolvimento de Software Orientado a Aspectos

Sistema Multi- usurio Arquitetura, design

2 .2 .2 A bo rda g e m AO RE ut iliza ndo U ML

2.Desenvolvimento de Software Orientado a Aspectos

Nome Descrio Focus

Fonte da informao (documentos, stakeholders)

2.Desenvolvimento de Software Orientado a Aspectos

Nome Descrio Prioridade

2.Desenvolvimento de Software Orientado a Aspectos

2.Desenvolvimento de Software Orientado a Aspectos

<<overlapBy>> pagar fatura <<overlapBy>>

registrar veiculo <<wrappedBy>> Proprietrio do Veculo <<wrappedBy>>

entrar na rodovia tempo de resposta <<wrappedBy>>

<<wrappedBy>> sair da rodovia Motorista