Tese Valter Final

Frameworks transversais: definioes, classificaoes,
arquitetura e utilizaao em um processo de

desenvolvimento de software
Valter Vieira de Camargo



Orientador: Prof. Dr. Paulo Cesar Masiero

Tese apresentada ao Instituto de Cincias Matemticas e
de Computao - ICMC-USP, como parte dos requisitos
para obteno do ttulo de Doutor em Cincias - Cincias
de Computao e Matemtica Computacional.

USP So Carlos
Agosto de 2006

SERVIO DE PS-GRADUAO DO ICMC-USP

Data de Depsito: 04/08/2006

Assinatura:________________________

II

III



IV

V

Ao meu pai (in memorian)

VI
Agradecimentos

Cinco anos se passaram e muitas coisas alegres e tristes aconteceram; casei, meu pai
se foi, meus cabelos caram, minha barriga cresceu, etc. Muitos acontecimentos marcantes,
uma quantidade imensa de histrias para contar, muitas amizades conquistadas. Um perodo
de crescimento sem limites. Entretanto, esta pgina marca o final desse perodo. Um fim que
no vou encarar com tristeza ou saudade, mas sim como uma nova vida, como uma nova
rotina que pretendo conduzir com a mesma perseverana, alegria e vontade com que despendi
durante o doutorado.
Gostaria de agradecer a Deus por me amparar nos momentos difceis que passei
durante o doutorado e tambm por me conceder momentos felizes.
Um agradecimento especial ao meu pai. Embora no esteja mais conosco, tenho
certeza que est me olhando l de cima com muito orgulho. Ele foi uma pessoa que me
moldou com poucas palavas e sem puxes de orelha. Seus ensinamentos vieram at mim por
demonstraes de como viver, como respeitar as pessoas e como valorizar cada momento
pequeno da vida. Seu olhar dizia tudo, no eram necessrias palavras. Apesar da pouca
escolaridade, sua personalidade e carter eram de um rei. Muito obrigado meu pai, o Sr. fez
de mim um homem.
Um agradecimento especial ao meu orientador Masiero. Sem dvida, sem ele nada
teria se concretizado. Cresci a ponto de saber que, no futuro, quando eu me lembrar desta
fase, verei o quanto eu era imaturo e quanto de conhecimento eu ainda faltava adquirir.
Tambm gostaria de enaltecer minha me. O simples fato de ela existir j me fornece
o suficiente para continuar lutando com a vida. O trmino de um trabalho como este sem
dvida no seria possvel sem o apoio emocional que ela me concede.
Minha esposa tambm merece grande parte desta conquista. S pessoas que j
passaram por isso sabem como conviver com um doutorando em Cincia da Computao.
Inmeros finais de semana perdidos e trancafiados em casa. Liriane, parte deste ttulo de
doutorado tambm seu.
Tambm vai um agradecimento especial minha irm, meu cunhado e meus dois
sobrinhos Murilo e Camilo. Embora o pouco tempo que tenho me dedicado a vocs durante
estes cinco anos, os sorvetes de domingo tarde foram muito importantes para mim.
Outra pessoa que merece um agradecimento especial a Professora Rosngela
Penteado, hoje minha amiga e madrinha de casamento, no passo minha orientador de

VII
mestrado. Pessoa extraordinria que uma das grandes responsveis por eu ter chegado at
aqui. Sua bondade e presteza algo fora do normal. Gosto muito de voc.
Grande agradecimento ao velho amigo Ricardo Ramos que esteve presente nos
momentos mais importantes de minha vida. Uma pessoa com quem eu sempre pude contar em
qualquer tipo de situao.
Aos grandes amigos do condomnio SGF (Santa Guerra Ferro), Dinho, Pablo e
Alexandre. impossvel esquecer das peripcias que fazamos juntos. Tenho muita saudade
daquele tempo.
Aos grandes amigos do Labes: Fabiano, Otvio, Marcelo, Stanley, KLB (Sandro),
Reginaldo, Erika, Bira, Elisa, Marcella, Dbora, Maris, Alessandra, Paula, Antonielly, Andr,
Camila, Rogrio, Adenilso, Luciana, Ellen e Rosana.
Tambm gostaria de agradecer ao professor Ferno Germano, que me apoiou no fim
do mestrado/incio do doutorado.
Agradeo tambm ao professor Maldonado por dar espao em suas disciplinas de ps-
graduaao para a conduo de experimentos.
Agradeo a todos funcionrios do ICMC que de forma direta ou indireta contriburam
para a realizao desta tese de doutorado.
Agradeo Capes pelo apoio financeiro.

VIII
Sumrio
CAPTULO 1 INTRODUO............................................................................................................................... 1
1.1 CONTEXTUALIZAO ................................................................................................................................. 1
1.2 MOTIVAO............................................................................................................................................... 2
1.3 OBJETIVOS.................................................................................................................................................. 3
1.4 ORGANIZAO DO TEXTO.......................................................................................................................... 3
CAPTULO 2 FRAMEWORKS E PROCESSOS NO CONTEXTO DA POA.................................................. 5
2.1 - CONSIDERAES INICIAIS ........................................................................................................................... 5
2.2 - SEPARAO DE INTERESSES E PROGRAMAO ORIENTADA A ASPECTOS................................................... 5
2.2.1 Apoio Lingstico para a Programao Orientada a Aspectos........................................................10
2.2.2 Interfaces de Entrecorte ...................................................................................................................12
2.3 FRAMEWORKS DE SOFTWARE ORIENTADOS A OBJETOS ............................................................................13
2.3.1 Modelagem de Frameworks com o Perfil UML-F............................................................................16
2.3.2 Linhas de Produtos e Frameworks Orientados a Objetos................................................................17
2.4 FRAMEWORKS NO CONTEXTO DA POA.....................................................................................................19
2.4.1 Frameworks de Persistncia no Contexto da POA............................................................................20
2.4.2 Frameworks de Segurana no Contexto da POA .............................................................................22
2.4.3 Frameworks de Aplicao no Contexto da POA..............................................................................26
2.4.4 Modelagem de Aspectos ...................................................................................................................28
2.4.5 Tcnicas de Implementao de Aspectos Genricos.........................................................................35
2.4.6 Linhas de Produtos e a Programao Orientada a Aspectos...........................................................39
2.5 PROCESSO DE DESENVOLVIMENTO ORIENTADO A ASPECTOS....................................................................39
2.6 CONCLUSO..............................................................................................................................................43
CAPTULO 3 FRAMEWORKS TRANSVERSAIS: DEFINIES, CLASSIFICAES E
ARQUITETURA....................................................................................................................................................... 45
3.1 CONSIDERAES INICIAIS..........................................................................................................................45
3.2 FRAMEWORKS ORIENTADOS A ASPECTOS: DEFINIES E CLASSIFICAES..............................................45
3.3 PROPOSTA DE UMA ARQUITETURA PARA FRAMEWORKS TRANSVERSAIS ..................................................51
3.3.1- Exemplo de Utilizao do Padro Capturador de Dados..................................................................60
3.4 - CONSIDERAES FINAIS ............................................................................................................................67
CAPTULO 4 FAMLIAS DE FRAMEWORKS TRANSVERSAIS................................................................ 69
4.1 CONSIDERAES INICIAIS..........................................................................................................................69
4.2 FAMLIAS DE FRAMEWORKS TRANSVERSAIS .............................................................................................69
4.3 FAMLIA DE FRAMEWORKS TRANSVERSAIS DE PERSISTNCIA...................................................................71
4.3.1 Processo de Reso do FT de Persistncia........................................................................................81
4.3.2 Adaptaes no FT de Persistncia....................................................................................................87
4.3.3 Acoplamento de Caractersticas ao FT de Persistncia...................................................................90
4.3.4 O FT de Garantia de Polticas .........................................................................................................95
4.4 FAMLIA DE FRAMEWORKS TRANSVERSAIS DE SEGURANA.....................................................................97
4.5 FAMLIA DE FRAMEWORKS TRANSVERSAIS DE REGRAS DE NEGCIO .....................................................105
4.6 - CONSIDERAES FINAIS ..........................................................................................................................105
CAPTULO 5 ESTUDOS DE CASO ................................................................................................................. 107
5.1 CONSIDERAES INICIAIS........................................................................................................................107
5.2 - UM ESTUDO COMPARATIVO DO TEMPO DE COMPOSIO ENTRE FTS......................................................107
5.2.1 - Definio do estudo.........................................................................................................................111
5.2.2 - Planejamento do estudo ..................................................................................................................111
5.2.3 - Execuo. ........................................................................................................................................114
5.2.4 Dados Coletados.............................................................................................................................114
5.2.5 - Anlise dos Dados...........................................................................................................................116
5.2.6 Resultados Parciais ........................................................................................................................118
5.2.7 Ameaas Validade do Estudo ......................................................................................................122
5.2.8 Concluso do Estudo de Caso ........................................................................................................122
5.3 ANLISE DA DIFICULDADE DE ACOPLAMENTO .......................................................................................123
5.4 ESTUDOS PARA APOIAR O DESENVOLVIMENTO E TESTES DOS FTS .........................................................127
5.5 CONSIDERAES FINAIS..........................................................................................................................128

IX
CAPTULO 6 - PROFT - UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE APOIADO
POR FRAMEWORKS TRANSVERSAIS............................................................................................................ 131
6.2 VISO GERAL DO PROFT/PU..................................................................................................................132
6.3 FASE DE CONCEPO ..............................................................................................................................133
6.3.1 Disciplina Requisitos......................................................................................................................134
6.4 FASE DE ELABORAO............................................................................................................................142
6.4.1 Disciplina Anlise...........................................................................................................................143
6.4.2 Disciplina Projeto...........................................................................................................................150
6.4.3 Disciplina Implementao..............................................................................................................169
6.4.4 Planejar Iteraes ...........................................................................................................................173
6.5 FASE DE CONSTRUO............................................................................................................................173
6.6 CONSIDERAES FINAIS..........................................................................................................................174
CAPTULO 7 - EXEMPLO DE USO DO PROFT/PU........................................................................................ 177
7.2 FASE DE CONCEPO ..............................................................................................................................178
7.2.1 Disciplina Requisitos......................................................................................................................178
7.3 FASE DE ELABORAO 1. ITERAO...................................................................................................181
7.4 FASE DE ELABORAO 2. ITERAO...................................................................................................191
7.4.3 - Projetar Acoplamento dos Aspectos com a Base ............................................................................201
7.5 FASE DE CONSTRUAO 1 ITERAO ....................................................................................................206
7.6 FASE DE CONSTRUO 2. ITERAO ...................................................................................................209
7.6.4 - Planejar Iteraes...........................................................................................................................219
7.7 FASE DE CONSTRUO 1. ITERAO ASPECTUAL................................................................................220
7.7.2 - Disciplina Implementao...............................................................................................................222
7.8 FASE DE CONSTRUO 2. ITERAO ASPECTUAL................................................................................223
7.8.1 - Disciplina Projeto ...........................................................................................................................223
7.9 - CONSIDERAES FINAIS ..........................................................................................................................227
CAPTULO 8 - CONCLUSO.............................................................................................................................. 231
8.2 CONTRIBUIES DESTA TESE..................................................................................................................232
8.3 LIMITAES DO TRABALHO EFETUADO ..................................................................................................233
8.3.1 Limitaes relacionadas aos FTs ...................................................................................................233
8.3.2 Limitaes relacionadas ao Processo ProFT/PU ..........................................................................234
8.3 SUGESTES DE TRABALHOS FUTUROS.....................................................................................................234
REFERNCIAS BIBLIOGRFICAS .......................................................................................................................237
ANEXO 1 - DOCUMENTO DE REQUISITOS DO SISTEMA DE RESERVAS DE UMA REDE DE HOTIS ......................247
ANEXO 2 - FORMULRIO DE CARACTERIZAO DO PERFIL .............................................................................251
ANEXO 3 - Q1 QUESTIONRIO INDIVIDUAL PARA PARTICIPANTES DO ESTUDO DE CASO..............................253
ANEXO 4 - RELATRIO DE IMPLEMENTAO DO FRAMEWORK DE PERSISTNCIA E SEGURANA ORIENTADO A
ASPECTOS.........................................................................................................................................................255

X
Anexos

Anexo 1 Documento de Requisitos do Sistema de Reservas de uma Rede de Hotis
Anexo 2 Formulrio de Caracterizao do Perfil
Anexo 3 Q1 Questionrio Individual para Participantes do Estudo de Caso
Anexo 4 Relatrio de implementao do framework de persistncia e segurana orientado a
aspectos

XI

XII
Lista de Figuras

Figura 2.1 Diagrama de Classes de um Editor Grfico (Elrad et al., 2001) ...........................7
Figura 2.2 Implementao Orientada a Objetos do Interesse de Atualizao do Display.......8
Figura 2.3 Implementao do Mecanismo de Atualizao do Display................................11
Figura 2.4 Aspecto Abstrato ..............................................................................................12
Figura 2.5 Aspecto Concreto .............................................................................................12
Figura 2.6 Framework de Segurana Orientado a Aspectos (Vanhaute et al., 2001) ..........23
Figura 2.7 - Estrutura do Framework (Vanhaute et al., 2001)...............................................23
Figura 2.8 Aspecto Genrico de Criptografia da Biblioteca JASL......................................24
Figura 2.9 Aspecto de Autenticao...................................................................................26
Figura 2.10 Aspecto de Controle de Acesso.......................................................................27
Figura 2.11 Tema Transversal de Registro de Execuo ....................................................30
Figura 2.12 Composio entre os Tema Log e Base...........................................................31
Figura 2.13 Tema Composto..............................................................................................32
Figura 2.14 Modelagem de Arquitetura Orientada a Aspectos............................................34
Figura 2.15 Exemplos de Conjunto de Juno....................................................................38
Figura 3.1 Inverso de Controle nos Framelets e nos Frameworks Transversais.................49
Figura 3.2 Arquitetura de Referncia para Frameworks Transversais .................................52
Figura 3.3 Representao Esquemtica da Instanciao de um Framework Transversal .....52
Figura 3.4 Implementao Convencional de um FT de Pooling..........................................53
Figura 3.5 Projeto de um Framework Transversal Genrico...............................................55
Figura 3.6 Exemplo de Implementao do Padro..............................................................58
Figura 3.7 Modelo de Projeto do FT de Clculo Baseado em Tabela..................................61
Figura 3.8 Framework de Clculo Baseado em Tabela Instanciado ....................................64
Figura 3.9 Escolha de Variabilidades.................................................................................64
Figura 3.10 Ponto de Juno na Aplicao.........................................................................64
Figura 3.11 Aspecto da Regra de Negcio de Clculo do Vale-Refeio............................65
Figura 3.12 Ponto de Juno para o Acoplamento do Imposto de Renda ............................66
Figura 4.1 Diagrama de Caractersticas da Linha de Produtos de FTs de Persistncia.........75
Figura 4.2 Estrutura do Framework Transversal de Persistncia.........................................77
Figura 4.3 Cdigo do Aspecto PersistentEntities................................................................78
Figura 4.4 Cdigo do Aspecto OORelationalMapping .......................................................79
Figura 4.5 Aspecto ConnectionComposition......................................................................80
Figura 4.6 Cdigo do Aspecto PartialAwareness................................................................82
Figura 4.7 Classe DefaultConnection.................................................................................82
Figura 4.8 Framework de Persistncia como um Tema Transversal ...................................83
Figura 4.9 Composio do FT de Persistncia com uma Aplicao....................................84
Figura 4.10 Composio do Framework de Persistncia com Classes de aplicao
persistentes ...................................................................................................................85
Figura 4.11 Aspecto MyConnectionComposition...............................................................85
Figura 4.12 Modelo de Composio Resultante .................................................................86
Figura 4.13 Criao de Novos Mtodos .............................................................................88
Figura 4.14 Adaptao do Tipo Sobreposio do FT de Persistncia..................................89
Figura 4.15 Adaptao do Tipo Empacotamento................................................................90
Figura 4.16 FT de Pooling como um Tema Transversal .....................................................91
Figura 4.17 Acoplamento do FT de Pooling com o FT de Persistncia...............................93
Figura 4.18 Cdigo Fonte do Aspecto DefaultPoolingAspect.............................................94
Figura 4.19 Cdigo Fonte do Aspecto PoolWithoutReturn.................................................94
Figura 4.20 Modelo de Projeto Composto da Aplicao com a Caracterstica de Pooling...95
Figura 4.21 Modelo de Projeto do FT de Garantia de Polticas...........................................97

XIII
Figura 4.22 Cdigo do Aspecto pre_weaved_attributechecker ...........................................97
Figura 4.23 Arquitetura das Aplicaes em que o FT de Segurana pode ser Aplicado ......98
Figura 4.24 Diagrama de Caractersticas da Linha de Produtos de FTs de Segurana.........98
Figura 4.25 Modelo de Projeto do FT de Autenticao ....................................................101
Figura 4.26 Modelo de Projeto do FT de Polticas de Autenticao..................................102
Figura 4.27 Composio entre o FT de Polticas de Bloqueamento e o FT de Autenticao
...................................................................................................................................103
Figura 4.28 Composio com a Aplicao .......................................................................104
Figura 5.1 Acoplamento do Comportamento de Persistncia AO..................................109
Figura 5.2 Acoplamento do Comportamento de Persistncia OO..................................110
Figura 5.3 Acoplamento da Conexo AO......................................................................110
Figura 5.4 Acoplamento da Conexo - OO ......................................................................111
Figura 5.5 Projeto Experimental ......................................................................................112
Figura 5.6 (a) Experincia dos participantes em POA, Java e AspectJ; (b) Experincia dos
participantes nas linguagens JAVA e AspectJ (linhas de cdigo) ................................113
Figura 5.7 Diferenas Percentuais entre os Tempos de Composio (Primeira Fase)........116
Figura 5.8 - Diferenas Percentuais entre os Tempos de Composio (Segunda Fase) ........118
Figura 5.9 Comparao do Dado LC................................................................................121
Figura 5.10 Diagrama de Classes do Sistema de Caixa de Banco .....................................124
Figura 5.11 Mtodo CreateAccount()...............................................................................126
Figura 5.12 Ponto de Juno Real do Cdigo-Base ..........................................................127
Figura 6.1 As Fases do ProFT/PU....................................................................................133
Figura 6.2 Viso Geral do ProFT/PU...............................................................................133
Figura 6.3 Atividades Da Disciplina Requisitos que Despendem Maior Esforo na
Concepo..................................................................................................................135
Figura 6.4 Caso de Uso No-Funcional Autenticar Usurio Viso Individual de Caso de
Uso No-Funcional .....................................................................................................139
Figura 6.5 Caso de Uso Hipottico Fazer Reserva............................................................141
Figura 6.6 Atividades da Fase de Elaborao...................................................................144
Figura 6.7 Atividades da Disciplina Projeto.....................................................................151
Figura 6.8 Exemplo Hipottico de Caso de Uso Transversal ............................................154
Figura 6.9 Exemplo de Modelo de Projeto Combinado ....................................................164
Figura 6.10 Viso da Arquitetura.....................................................................................167
Figura 6.11 Atividades da Disciplina de Implementao..................................................170
Figura 7.1 Atores e Diagrama de Casos de Uso Inicial do Sistema de Reservas ...............178
Figura 7.2 - Caso de Uso No-Funcional Autenticar Usurio Viso Individual de Caso de
Uso.............................................................................................................................179
Figura 7.3 Caso de Uso Fazer Reserva.............................................................................180
Figura 7.4 Viso de Iterao Fase de Concepo...........................................................182
Figura 7.5 Caso de Uso Enviar Dados por E-mail ............................................................182
Figura 7.6 Modelo Conceitual do Sistema de Reservas ....................................................183
Figura 7.7 Viso de Acoplamento do FT de Persistncia com o Sistema de reservas ........185
Figura 7.8 Diagrama de Colaborao para a Operao Fazer Reserva ..............................186
Figura 7.9 Modelo de Classes de Projeto com Classes Controladoras...............................187
Figura 7.10 Acoplamento da Parte de Conexo do FT de Persistncia com a Parte Base da
Aplicao....................................................................................................................188
Figura 7.11 Viso da Arquitetura 1. Iterao da Elaborao.........................................188
Figura 7.12 Aspecto MyOORelationalMapping...............................................................190
Figura 7.13 Aspecto MyConnectionVariabilities..............................................................191
Figura 7.14 Aspecto de Acoplamento da Conexo ...........................................................191
Figura 7.15 Viso de Iterao para a Segunda Iterao do Sistema de Reservas ...............192

XIV
Figura 7.16 Viso Individual para o Caso de Uso Identificar Reserva ..............................193
Figura 7.17 Viso de Iterao para a Segunda Iterao do Sistema de Reservas ...............194
Figura 7.18 Modelo Conceitual Atualizado......................................................................195
Figura 7.19 Projeto do Aspecto Funcional Gerenciar Empresas .......................................201
Figura 7.20 Modelo de Classes de Projeto para o Sistema de Reservas 2. Iterao .......201
Figura 7.21 Composio entre Temas Base......................................................................202
Figura 7.22 Tema resultante da composio Modelo de Classes de Projeto 2a. Iterao
...................................................................................................................................202
Figura 7.23 Viso da Arquitetura 2. Iterao da Elaborao.........................................203
Figura 7.24 Viso de Acoplamento para o Sistema de Reservas 2. Iterao da Elaborao
...................................................................................................................................204
Figura 7.25 Aspecto EmpresasConveniadas.....................................................................205
Figura 7.26 Atualizao do Aspecto MyPersistentEntities ...............................................206
Figura 7.27 Atualizao das Regras de Composio da Conexo.....................................206
Figura 7.28 Viso de Casos de Uso da Iterao Atual 1. Iterao da Construo..........207
Figura 7.29 Modelo de Classes de Projeto para o Sistema de Reservas 1a. Iterao da
Construo..................................................................................................................209
Figura 7.30 Atualizao das Regras de Composio 1. Iterao da Construo............210
Figura 7.31 Viso de Iterao para o Sistema de Reservas 2. Iterao da Construo...211
Figura 7.32 Caso de Uso Reajustar Valor das Dirias ......................................................213
Figura 7.33 Modelo de Projeto do FT de Reajuste de Valor Instanciado...........................216
Figura 7.34 Acoplamento FT de Reajuste de Valor com Aplicao Base .........................217
Figura 7.35 Viso da Arquitetura 2a. Iterao da Construo........................................217
Figura 7.36 Atualizao das Regras de Composio da Conexo.....................................218
Figura 7.37 Classe MyAllCategories................................................................................218
Figura 7.38 Aspecto MyReadjustmentPolicy ...................................................................219
Figura 7.39 Viso de Iterao 3a. Iterao da Construo .............................................221
Figura 7.40 Viso da Arquitetura do Sistema...................................................................221
Figura 7.41 Aspecto MeuAspecto....................................................................................222
Figura 7.42 Modelo de Projeto Composto do Sistema de Reservas 1a. Iterao Aspectual
...................................................................................................................................223
Figura 7.43 Viso de Iterao para o Sistema de Reservas 2. Iterao Aspectual da
Construo..................................................................................................................224
Figura 7.44 Modelo de Projeto do FT de Controle de Acesso 3a. Iterao Aspectual ....225
Figura 7.45 Modelo de Projeto Instanciado......................................................................226
Figura 7.46 Acoplamento com o FT de Autenticao.......................................................226
Figura 7.47 Acoplamento com a Aplicao......................................................................227
Figura 7.48 Modelo de Projeto Composto........................................................................228
Figura 7.49 Viso da Arquitetura.....................................................................................228

XV

XVI
Lista de Tabelas

Tabela 2.1 Etiquetas da UML-F.........................................................................................17
Tabela 2.2 Idiomas de Hanenberg e Unland.......................................................................36
Tabela 3.1 Alternativas do Padro de Composio.............................................................54
Tabela 3.2 Modelo de Deciso...........................................................................................55
Tabela 3.3 Tabela do Framework de Regra de Negcio para o Clculo do Imposto de Renda
.....................................................................................................................................60
Tabela 3.4 Alternativas de Composio do FT de Clculo Baseado em Tabela ..................62
Tabela 3.5 Tabela para Clculo do Vale-Refeio..............................................................63
Tabela 4.1 Frameworks Transversais .................................................................................70
Tabela 4.2 Operaes do FT de Persistncia .....................................................................73
Tabela 5.1 Significado das Siglas dos Dados Coletados ...................................................109
Tabela 5.2 Hipteses para o Efeito do Framework de Persistncia ...................................111
Tabela 5.3 Hipteses para o Efeito do Uso das Aplicaes no Resultado .........................112
Tabela 5.4 Hipteses para o Efeito do Grupo ou Efeito da Interao................................112
Tabela 5.5 Primeira Etapa da Primeira Fase Composio com o Framework Orientado a
Objetos .......................................................................................................................114
Tabela 5.6 Segunda Etapa da Primeira Fase Composio com o FT de Persistncia......115
Tabela 5.7 Primeira e Segunda Etapas da Segunda Fase do Estudo..................................115
Tabela 5.8 Tempo Mdio dos Passos de Composio da Primeira e Segunda Fases .........119
Tabela 5.9 Tempo de Cada Atividade ..............................................................................125
Tabela 5.10 Aplicaes Desenvolvidas ............................................................................128
Tabela 6.1 Atividades do ProFT/PU ................................................................................134
Tabela 6.2 Modelo para Tabela de Correspondncia Caso de Uso/Requisitos ..................137
Tabela 6.3 Tabela de Correspondncia Caso de Uso/Requisitos Fase de Concepo .....137
Tabela 6.4 - Modelo para Tabela de Interesses Transversais No-Funcionais.....................138
Tabela 6.5 Modelo para Tabela de Descrio de Caso de Uso No-Funcional..................138
Tabela 6.6 Modelo de Tabela para Classificao de Casos de Uso e Planejamento de
Iteraes .....................................................................................................................142
Tabela 6.7 Tabela de Deciso para Identificao de Novos Casos de Uso ........................145
Tabela 6.8 Modelo de Matriz de Comparao de Casos de Uso para a Pergunta 1...........146
Tabela 6.9 Modelo para Tabela de Candidatos a Aspectos ...............................................148
Tabela 6.10 Critrios para Identificao de Aspectos .......................................................153
Tabela 6.11 Lista de Requisitos No-Funcionais Clssicos .............................................153
Tabela 6.12 Modelo para Tabela de Aspectos ..................................................................158
Tabela 6.13 Modelo de Tabela de Acompanhamento da Implementao dos Aspectos ....160
Tabela 6.14 Modelo para o Registro de Pontos de Juno................................................168
Tabela 7.1 Tabela de Interesses Transversais No-Funcionais para o Sistema de Reservas
...................................................................................................................................178
Tabela 7.2 Classificao de Casos de Uso para o Sistema de Reservas.............................179
Tabela 7.3 Tabela de Planejamento das Iteraes do Sistema de Reservas .......................181
Tabela 7.4 Tabela de Candidatos a Aspectos do Sistema de Reservas (TPCaUT).............182
Tabela 7.5 Tabela de Aspectos para o Sistema de Reservas 1 Iterao .........................183
Tabela 7.6 Tabela de Acompanhamento da Implementao de Aspectos para o Sistema de
Reservas .....................................................................................................................184
Tabela 7.7 Registro dos Pontos de Juno........................................................................189
Tabela 7.8 Tabela de Candidatos a Aspectos....................................................................195
Tabela 7.9 Tabela de Aspectos para o Sistema de Reservas 2 Iterao ........................196
Tabela 7.10 Faixas de Descontos .....................................................................................198

XVII
Tabela 7.11 Tabela de Acompanhamento da Implementao de Aspectos para o Sistema de
Reservas 2 Iterao.................................................................................................199
Tabela 7.12 Registro de Pontos de Juno 2. Iterao da Elaborao............................204
Tabela 7.13 Registro de Pontos de Juno 1a. Iterao da Construo...........................210
Tabela 7.14 Tabela de Candidatos a Aspectos..................................................................212
Tabela 7.15 Tabela de Aspectos para o Sistema de Reservas 2a. Iterao da Construo
...................................................................................................................................212
Tabela 7.16 Tabela de Acompanhamento da Implementao dos Aspectos......................213
Tabela 7.17 Tabela de Aspectos para o Sistema de Reservas............................................214
Tabela 7.18 Tabela de Acompanhamento da Implementao dos Aspectos......................215
Tabela 7.19 Registro de Pontos de Juno 2a. Iterao da Construo...........................218
Tabela 7.20 Tabela de Aspectos Atualizada.....................................................................220
Tabela 7.21 Classificao dos Casos de Uso Aspectuais ..................................................220
Tabela 7.22 Tabela de Planejamento das Iteraes do Sistema de Reservas......................220
Tabela 7.23 Registro de Pontos de Juno .......................................................................222
Tabela 7.24 Registro de Pontos de Juno .......................................................................229

XVIII
Resumo

O paradigma orientado a objetos no dispe de abstraes adequadas
modularizao de interesses transversais interesses cuja implementao
encontra-se entrelaada e espalhada por todos os mdulos de um sistema.
Com o surgimento da Programao Orientada a Aspectos e a
disponibilidade de abstraes adequadas modularizao de interesses
transversais, o reso desses interesses foi facilitado. Nesta tese so
apresentados alguns resultados de esforos de pesquisa que visam a tornar o
reso de interesses transversais mais efetivo. Definies e classificaes
para frameworks desenvolvidos no contexto da POA frameworks
transversais so apresentadas com o objetivo de facilitar a comunicao
entre usurios e pesquisadores. Uma arquitetura de referncia para o projeto
e implementao de frameworks transversais, que torna sua estrutura mais
clara e facilita a integrao de vrios frameworks quando a inteno criar
um repositrio de aspectos reusveis, proposta. Trs famlias de
frameworks transversais: de persistncia, de segurana e de regras de
negcio foram desenvolvidas. Cada famlia de frameworks transversais
constitui uma linha de produtos de software, em que membros podem ser
configurados com caractersticas (features) distintas. Um processo de
desenvolvimento, denominado ProFT/PU, baseado no Processo Unificado
(PU), que considera as famlias de frameworks ao longo de todo o processo
apresentado, juntamente com um exemplo de sua utilizao para uma
aplicao tpica. Um estudo de caso para comparar o tempo requerido para
reusar um framework transversal de persistncia e um framework orientado
a objetos de persistncia tambm apresentado e discutido.

XIX

XX
Abstract
The object-oriented paradigm does not provide adequate abstractions to
modularize crosscutting concerns concerns whose implementation end up
tangling and spreading throughout the modules of a system. With the
emerging of Aspect-Oriented Programming (AOP) and the availability of
abstractions suitable to modularize crosscutting concerns, the reuse of such
concerns is facilitated. In this thesis, some results of research efforts to
make the reuse of crosscutting concerns more effective are presented.
Definitions and classifications for frameworks developed in the context of
AOP crosscutting frameworks - with the objective of improving
understanding and communication among users and researchers are
presented. An architecture specifically to design and implement this type of
framework, which makes its structure clearer and facilitates the integration
of several frameworks, is proposed. Three families of crosscutting
frameworks for persistence, security and business rules, were developed.
Each crosscutting framework family is a software product line, in which
members can be instantiated with distinct characteristics. A development
process, named ProFT/PU, based on Unifed Process (UP), which takes into
account the families during the process, is presented, along with an example
of its use for a typical application. A case study to compare the time
required to reuse a persistence crosscutting framework and a persistence
object-oriented framework is also presented and discussed.

XXI

Captulo 1
vt r oav ao
J.J CON1LX1UALIZAO
Na dcada de 70 surgiram os primeiros trabalhos que se referiam ao termo interesse como
um conceito de modularizao de software (Dijkstra, 1976). Muito do que se props nessa
poca e em pesquisas subseqentes foi sendo gradativamente incorporado s linguagens de
programao e aos modelos de processo de desenvolvimento de software, culminando na
dcada de 90 com o desenvolvimento orientado a objetos e a padronizao propiciada pela
UML (Unified Modelling Language) (Jacobson et al., 1999).
A Programao Orientada a Aspectos (POA) (Gregor Kiczales et al., 1997) e a
linguagem AspectJ (Kiczales et al., 2001) surgiram no final da dcada de 90 como uma
importante contribuio para modularizar interesses transversais, que at ento ficavam
misturados e espalhados pelo cdigo orientado a objetos, sem que fosse possvel organiz-los
em mdulos independentes. A POA fornece novas abstraes que contribuem para a
separao de interesses (separation of concerns) um objetivo antigo da engenharia de
software que visa a separar os interesses encontrados no cdigo-fonte de um sistema
(Dijkstra, 1976). Com a POA possvel implementar separadamente os interesses-base e os
interesses transversais, o que at ento era dificultado somente com orientao a objetos. Os
interesses-base referem-se funcionalidade principal do sistema e os transversais referem-se a
restries globais e a requisitos no-funcionais, como, por exemplo: persistncia, distribuio,
autenticao, controle de acesso e concorrncia.
A partir desse avano, outras linguagens de programao orientadas a aspectos
surgiram e iniciou-se um processo de reviso das tcnicas, mtodos e processos usados at
ento para adapt-las a essa nova forma de pensar o software e modulariz-lo, tais como
tcnicas de elicitao e modelagem de requisitos (Grundy, 1999; Jacobson e Ng, 2004)
Captulo 1 - Introduo

2
(Clarke e Baniassad, 2005; Rashid et al., 2002; Baniassad et al., 2006; Arajo e Moreira,
2003; Arajo et al., 2002), linguagens de modelagem para projeto (Berg et al., 2006; Clarke e
Baniassad, 2005; Grundy, 2000; Katara e Katz, 2003; Suzuki e Yamamoto, 1999; Pawlak et
al., 2002; Stein et al., 2002; Zakaria et al., 2002; Aldawud et al., 2003), tcnicas de teste
(Lemos et al, 2003a; Lemos et al., 2003b; Zhao, 2003; Zhao, 2002; Zhou et al., 2004) e uso
de aspectos para implementar variabilidades em linhas de produto de software (Mezini e
Ostermann, 2004; Batory et al., 2006).
Como a implementao de interesses transversais em unidades sintticas abstratas
tambm possvel com a POA, vrios pesquisadores iniciaram pesquisas com o objetivo de
implementar esses interesses de forma genrica para investigar seu reso em outros contextos,
criando assim, frameworks orientados a aspectos
1
que encapsulam um nico interesse
transversal (Couto et al., 2005; Hanenberg et al., 2004; Huang et al., 2004; Shah e Hill, 2004;
Constantinides et al., 2000; Pinto et al, 2002; Rashid e Chitchyan, 2003; Soares et al., 2002;
Vanhaute et al., 2001).
Embora a maioria destes pesquisadores investigue o projeto e a implementao de um
nico framework, trabalhos mais recentes mostram uma tendncia em agrupar aspectos
reusveis em um repositrio bibliotecas ou famlias para apoiar o reso durante o processo
de desenvolvimento de uma aplicao (Zhang et al., 2004; Mortensen e Ghosh, 2006a;
Mortensen e Ghosh, 2006b; Soares, 2004).
J.2 MO1IVAO
A modularizao de interesses transversais difcil quando apenas orientao a objetos
usada. Em conseqncia disso, poucos avanos significativos foram conseguidos em relao
ao reso desses interesses at o aparecimento da POA. Depois de seu surgimento, o reso de
interesses transversais emergiu como uma linha de pesquisa importante, atraindo vrios
pesquisadores e gerando muitas propostas e iniciativas de desenvolvimento de frameworks
orientados a aspectos (Rashid and Chitchyan, 2003; Couto et al., 2005; Camargo e Masiero,
2005a; Soares et al., 2002; Rausch et al., 2003; Vanhaute et al., 2001; Chen e Huang, 2005;
Zubairov et al., 2005; Zhang et al., 2004; Mortensen e Ghosh, 2006a; Mortensen e Ghosh,
2006b; Pinto et al., 2001a; Pinto et al., 2001b; Pinto et al., 2002; Hanenberg et al., 2004).
Entretanto, o reso de interesses transversais ainda hoje se encontra em fase de
amadurecimento, pois os termos utilizados pelos pesquisadores muitas vezes so diferentes

1
Deste ponto em diante, o termo framework orientado a aspectos ser usado para designar uma
implementao genrica de um nico interesse transversal, at que uma definio mais precisa seja apresentada
no Captulo 3.
3
para conceitos ou solues semelhantes. Alm disso, h uma carncia por padres de
arquitetura e de projeto de software bem estabelecidos. Assim, possvel concluir que este
um campo atual e promissor para novas pesquisas. Nesse contexto, a pesquisa apresentada
nesta tese visa a contribuir para o ruso de projeto e de cdigo de interesses transversais.
J.3 OBJL1IVOS
O objetivo geral desta tese tornar o reso de interesses transversais mais efetivo durante o
desenvolvimento de uma aplicao. Para isso, prope uma arquitetura de referncia para o
projeto e a implementao de frameworks orientados a aspectos. Essa arquitetura padro
separa a parte funcional da parte de composio, contribuindo para uma melhor compreenso
de sua estrutura e facilitando a sua evoluo. A aderncia a uma arquitetura padro tambm
facilita a integrao de vrios frameworks em um repositrio de apoio ao reso, como
bibliotecas ou famlias de frameworks orientados a aspectos, o que introduz sistematizao no
processo de reso.
Como apoio tecnolgico, trs famlias de frameworks orientados a aspectos so
propostas: de persistncia de dados, de segurana e de regras de negcio (Weiss e Lai, 1999;
Gomaa, 2004). Para facilitar o uso dessas famlias, tambm proposto um processo de
desenvolvimento de software apoiado por frameworks orientados a aspectos. O processo,
denominado ProFT/PU, baseado no PU (Jacobson et al., 1999); iterativo e incremental; e
considera a identificao e o acompanhamento de interesses transversais ao longo de todo o
processo. Ele sintetizado pela unio de conceitos, tcnicas de modelagem e critrios de
outros trabalhos encontrados na literatura (Clarke e Baniassad, 2005; Jacobson e Ng, 2004;
Arajo e Moreira, 2003; Arajo et al., 2002).
J.4 ORGANIZAO DO 1LX1O
No Captulo 2, os conceitos fundamentais para o entendimento da tese so apresentados
juntamente com trabalhos diretamente relacionados com a pesquisa realizada. O objetivo
mostrar o paranorama atual dos campos de pesquisa relacionados a esta tese e justificar o
trabalho proposto.
No Captulo 3, algumas definies e classificaes para frameworks orientados a
aspectos so propostas com o objetivo de homogeneizar o termo e melhorar a comunicao
entre desenvolvedores. Ainda nesse captulo, uma arquitetura para o projeto e a
implementao de frameworks orientados a aspectos discutida e exemplificada.

4
No Captulo 4, as famlias de frameworks orientados a aspectos para persistncia de
dados e para segurana so apresentadas e discutidas.
No Captulo 5, trs estudos de caso so relatados. Alguns foram conduzidos com o
objetivo de evoluir e testar os frameworks desenvolvidos, enquanto os outros tiveram o
propsito de comparar e averiguar algumas de suas particularidades.
No Captulo 6, um processo de desenvolvimento de software, denominado ProFT/PU,
apresentado. Esse processo ilustrado no Captulo 7 com sua aplicao no desenvolvimento
de um sistema de reserva de uma rede de hotis.
As contribuies desta tese e algumas propostas de continuidade das pesquisas aqui
coduzida so apresentadas no Captulo 8.

Captulo 2
r ave ror /. e Pr oc e. .o. vo Covt et o aa
PO.
2.J - CONSIDLRALS INICIAIS
Neste captulo so apresentados e discutidos os conceitos fundamentais para o entendimento
desta tese e tambm os trabalhos diretamente relacionados com a pesquisa conduzida. Uma
abordagem histrica mostrando brevemente a evoluo das pesquisas desde o aparecimento
do conceito de separao de interesses at a programao orientada a aspectos mostrada.
O escopo do trabalho delimitado, discutindo especificamente frameworks orientados a
objetos e alguns frameworks orientados a aspectos. Alguns trabalhos que discutem
modelagem e implementao de frameworks orientados a aspectos so apresentados e
tambm feita uma reviso da literatura sobre trabalhos que relacionam linhas de produtos e
POA. Por fim, alguns trabalhos que tratam os interesses transversais durante o processo de
desenvolvimento so apresentados.
Na Seo 2.2 uma introduo aos conceitos de POA e separao de interesses
mostrada e na Seo 2.3 as principais particularidades dos frameworks orientados a objetos
so apresentadas. Na Seo 2.4, o desenvolvimento de frameworks no contexto da POA
discutido, juntamente com exemplos de frameworks orientados a aspectos encontrados na
literatura. Na Seo 2.5, trabalhos que tratam de processos de desenvolvimento de software
orientados a aspectos so mostrados, e na Seo 2.6, oportunidades de pesquisa com base nos
trabalhos apresentados anteriormente so discutidas.
2.2 - SLPARAO DL IN1LRLSSLS L PROGRAMAO
ORILN1ADA A ASPLC1OS
Captulo 2 Reviso Bibliogrfica

6
A separao de interesses (separation of concerns) um princpio bem estabelecido na
engenharia de software que se refere limitao da cognio humana em lidar com a
complexidade de um software (Dijkstra, 1976). Apesar de no ter sido um pesquisador de
Psicologia Cognitiva, a estratgia proposta por Dijkstra foi amplamente aceita pelas
comunidades de Cincia da Computao e de Engenharia de Software para resolver o
problema complexo de desenvolver um sistema de software. A estratgia consiste em, a cada
momento, focar a ateno em uma poro autocontida, ou interesse, isoladamente, tendo-se
cincia de que se est ignorando temporariamente outras partes do problema.
Desde sua criao, a separao de interesses tem sido alvo constante de pesquisas na
rea de engenharia de software. A cada novo paradigma de programao criado, novas
construes sintticas eram fornecidas para modularizar mais adequadamente os interesses. O
objetivo era que sistemas de softwares complexos pudessem ser decompostos em um conjunto
de mdulos altamente coesos e com interface claramente definidas. Assim, o processo de
evoluo passou pela programao procedural, programao estruturada, programao lgica
e programao orientada a objetos, entre outras. O objetivo sempre foi melhorar a
inteligibilidade do sistema e tambm sua manuteno, reso e evoluo.
Continuando o processo de evoluo dos paradigmas de programao, em 1997,
Kiczales et al. (1997) publicaram um artigo apresentando a Programao Orientada a
Aspectos. A sua idia principal que sistemas so programados de forma mais adequada
distinguindo interesses transversais de interesses-base. Interesses-base referem-se
funcionalidade principal do sistema enquanto que um interesse transversal pode variar de
requisitos de alto nvel como segurana e qualidade de um servio a noes de baixo nvel,
como sincronizao e manipulaes de buffer de memria. Podem ser tanto funcionais, como
regras de negcio, quanto no-funcionais, como gerenciamento de transaes e persistncia de
dados. Alguns exemplos mais comuns so: sincronizao, interao de componentes,
persistncia, distribuio, gerenciamento de registros (logging) e controle de acesso (Kiczales
et al., 1997).
O termo interesse transversal faz analogia ao fato de que sua implementao com
tcnicas tradicionais de programao entrecorta transversalmente os mdulos do sistema,
afetando vrios mdulos e causando entrelaamento (tangling) e espalhamento (spreading) de
cdigo de diferentes interesses. O entrelaamento ocorre quando o cdigo de um determinado
interesse encontra-se misturado com o cdigo de um outro interesse dentro de um mesmo
mdulo. O espalhamento ocorre quando o cdigo de um interesse encontra-se em vrios
7
mdulos do sistema. O entrelaamento e o espalhamento de cdigo de diferentes interesses
causam problemas de manuteno, reso e evoluo.
A POA foi proposta como uma extenso da orientao a objetos, aproveitando todos
os seus conceitos, porm adicionando conceitos especficos para a modularizao dos
interesses transversais como, por exemplo: aspectos (aspects) e adendos (advices). Assim os
interesses transversais so implementados em mdulos aspectuais e os interesses-base em
classes normais. Uma das motivaes para a criao da POA foi o reconhecimento de que os
paradigmas de desenvolvimento de software convencionais, mais especificamente o orientado
a objetos, sofrem da Tirania da Decomposio Dominante. Consiste na existncia de apenas
um tipo de mdulo ou construo sinttica o mdulo dominante para se encapsular mais
de um tipo de interesse (Tarr et al., 2001). Alguns exemplos de mdulos dominantes so as
classes na programao orientada a objetos, as funes nas linguagens funcionais e as regras
na programao baseada em regras. Um paradigma que permite a decomposio em apenas
um tipo de mdulo chamado de unidimensional, pois h apenas uma dimenso para a
modularizao dos interesses, no importando quantos tipos de interesses existem.
A existncia de apenas um tipo de mdulo para encapsular mais de um tipo de
interesse faz com que aqueles interesses que envolvem restries globais os interesses
transversais no fiquem adequadamente encapsulados e acabem misturando-se com os
interesses-base.
Elrad et al. (2001) ilustram por meio da Figura 2.1 a natureza de um interesse
transversal. O diagrama mostrado de um editor de figuras que deve ser evoludo com a
incluso de um novo interesse, que consiste em notificar o mecanismo de exibio (classe
Display) toda vez que um elemento do tipo FigureElement for movimentado.

Figura 2.1 Diagrama de Classes de um Editor Grfico (Elrad et al., 2001)

Realizar essa operao de manuteno usando programao orientada a objetos resulta em
adicionar em todos os mtodos que alteram a posio de um ponto ou de uma linha (os
mtodos set*()) uma chamada ao mtodo updating() da classe Display, como
Figure FigureElement
n
Line
getP1()
getP2()
setP1(point : Point)
setP2(point : Point)
Point
getX()
getY()
setX()
setY()
2
n
2
Displ ay
updating()

8
mostrado em negrito na Figura 2.2. Note-se que o cdigo desse novo interesse ficou
entrelaado com o cdigo de cada um dos mtodos e espalhado por vrios mtodos do
sistema.
A POA introduz novas abstraes de modularizao e mecanismos de composio
para melhorar a separao de interesses transversais. As novas abstraes propostas pela POA
so: aspectos, pontos de juno (join points), conjuntos de juno (pointcus), adendos e
declaraes intertipos (inter-type declarations).
Aspecto o termo usado para denotar a abstrao da POA que d suporte a um melhor
isolamento de interesses transversais. Em outras palavras, um aspecto corresponde a um
interesse transversal e constitui uma unidade modular projetada para afetar um conjunto de
classes e objetos do sistema.

Figura 2.2 Implementao Orientada a Objetos do Interesse de Atualizao do Display
Os pontos de juno so pontos bem definidos da execuo de um sistema. Alguns
exemplos de pontos de juno so: chamadas a mtodos, execues de mtodos, leitura de
atributos e modificao de atributos. Por meio dos pontos de juno, torna-se possvel
especificar o relacionamento entre aspectos e classes. Por exemplo, um aspecto A afeta uma
classe C1 no instante da invocao de um mtodo M1. Em outro exemplo, o aspecto A afeta
uma classe C2 ao final da execuo de um mtodo M2. O instante da invocao do mtodo
M1 e o ponto final da linha de execuo do mtodo M2 so exemplos de pontos de juno.
Tais pontos de juno so os locais no programa onde os aspectos podem atuar. Eles podem
ser especificados em uma linguagem orientada a aspectos por meio da definio de conjuntos
de juno. Um conjunto de juno o mecanismo que especifica os pontos de juno em que
aspectos e classes se relacionam.
class Line
{
private Point p1, p2;

Point getP1() {return p1;}
Point getP2() {return p2;}

void setP1(Point p1)
{
this.p1 = p1;
Display.updating();
}
void setP2(Point p2)
{
this.p2 = p2;
Display.updating();
}
}

class Point
{
int x, int y;

int getX() { return x};
int getY() { return y}

void setX(int x)
{
this.x = x;
Display.updating();
}
void setY(int y)
{
this.y = y;
Display.updating()
}
}
9
A implementao do comportamento transversal modularizado por um aspecto feita
em adendos. Adendo um construtor semelhante a um mtodo de uma classe, que define o
comportamento dinmico executado quando so alcanados um ou mais conjuntos de juno
definidos previamente. Existem trs tipos adendos: os adendos anteriores (before), os
posteriores (after) e os de substituio (around). Os adendos anteriores so executados sempre
que os pontos de juno associados so alcanados e antes do prosseguimento da computao;
os adendos posteriores so executados no trmino da computao, ou seja, depois que os
pontos de juno forem executados e imediatamente antes do retorno do controle ao
chamador; os adendos de substituio tomam o controle do cdigo-base, podendo ou no
devolver o controle.
As declaraes intertipos podem ser utilizadas quando se deseja introduzir atributos e
mtodos em classes-base do sistema. Ao contrrio de adendos, que operam de forma
dinmica, as declaraes intertipos operam estaticamente, em tempo de compilao.
Um aspecto pode afetar a estrutura esttica ou dinmica de classes e objetos. A
estrutura dinmica afetada por meio da especificao de conjuntos de juno e adendos; a
estrutura esttica afetada por meio de declaraes intertipo.
Alm de especificarem elementos que entrecortam classes de um sistema, aspectos
podem possuir mtodos e atributos internos, como classes OO.
So trs as propriedades bsicas da POA (Kiczales et al., 1997; Elrad et al., 2001):
dicotomia aspectos-base: diz respeito adoo de uma distino clara entre classes e
aspectos. Os sistemas orientados a aspectos so decompostos em classes e aspectos.
Os aspectos modularizam os interesses transversais e as classes modularizam os
interesses-base;
inconscincia: propriedade desejvel da programao orientada a aspectos. a idia
de que os componentes no precisam ser preparados para serem entrecortados por
aspectos (Elrad et al., 2001). Pela propriedade de inconscincia, os componentes no
percebem os aspectos que podero afet-los. Embora seja uma propriedade
interessante, algumas pesquisas atuais comeam a apontar vantagens quando o cdigo-
base possui conscincia da existncia dos aspectos (Kiczales e Mezini, 2005;
Griswold, et al., 2006);
quantificao: capacidade de escrever declaraes unitrias e separadas que afetam
muitos pontos de um sistema (Elrad et al., 2001). Pela propriedade de quantificao,
possvel fazer declaraes do tipo em programas P, sempre que a condio C for
verdadeira, faa a ao A.

10
Combinador o mecanismo responsvel pela composio de classes e aspectos. Quase
todo o processo de combinao realizado como um pr-processamento em tempo de
compilao. Entretanto, a verso 5 da linguagem AspectJ j oferece suporte ao processo de
combinao dinmico, pela associao de mecanismos da linguagem com frameworks como
AspectWerkz (AspectWerkz Website 2006).
2.2.J Apoio Lingistico para a Programao Orientada a
Aspectos
H vrias abordagens lingsticas para a implementao de sistemas orientados a aspectos,
como, por exemplo: AspectC para a linguagem C, AspectC# para a linguagem C#, AspectS
(Hirschfeld, 2002) para a linguagem Smalltalk e AspectJ para a linguagem Java. Porm, como
AspectJ a linguagem mais difundida e a que foi utilizada para a implementao dos
frameworks desenvolvidos no contexto desta tese, ser a nica descrita com detalhes.
O desenvolvimento de software orientado a aspectos possui duas vertentes:
abordagens assimtricas e abordagens simtricas. As assimtricas consideram que um sistema
possui dois tipos de interesse: os base e os transversais. Assim, as linguagens que apiam
essas abordagens fornecem dois construtores sintticos para a implementao desses tipos de
interesses. Um exemplo de uma linguagem de programao que apia a abordagem
assimtrica AspectJ, pois ela possui classes para a implementao do interesses-base e
aspectos para a implementao dos interesses transversais. Quando esse tipo de abordagem
usado, modulariza-se com aspectos apenas os interesses transversais existentes em um
sistema, considerando todo o cdigo-base restante como um nico bloco indivisvel que
afetado pelos aspectos. Assim, seria mais correto dizer que esse tipo de abordagem considera
que o sistema possui um nico interesse-base e vrios transversais.
Por outro lado, as abordagens simtricas se concentram em dividir o sistema todo em
interesses, no fazendo distino entre transversais e bases. chamada de simtrica porque
a implementao de todos os interesses feita com um nico tipo de construo sinttica, por
exemplo: classes normais. Cada interesse-base poderia ser, por exemplo, um caso de uso, ou
mesmo uma funcionalidade do sistema. Uma linguagem que implementa a abordagem
simtrica a Hyper/J, a qual pode ser utilizada no ambiente CME (Concern Manipulation
Environment), um plug-in do ambiente Eclipse.
AspectJ implementa todos os conceitos da programao orientada a aspectos. Por
exemplo, na Figura 2.3 mostrada a implementao de um aspecto que visa a solucionar o
problema da atualizao do gerenciador de exibio mostrado na Figura 2.2. Esse aspecto
possui um conjunto de juno denominado move(), que especifica dois pontos de juno: o
11
primeiro so chamadas (call) a todos os mtodos que iniciam com as letras set da classe
Line e o segundo faz o mesmo para a classe Point. Quando h uma chamada a algum
mtodo set* da classe Line ou da classe Point, o adendo after chama o mtodo
updating() da classe Display aps o trmino da execuo desses mtodos chamados. O
smbolo | | entre os dois pontos de juno destacados com retngulo significa um operador
or. A declarao returning garante que o adendo after s ser executado se os pontos
de juno, do conjunto de juno move(), retornarem com sucesso de suas execues. Dessa
forma, as chamadas ao mtodo updating() da classe Display mostradas na Figura 2.2
poderiam ser removidas dos mtodos set*().

Figura 2.3 Implementao do Mecanismo de Atualizao do Display
A linguagem AspectJ tambm permite a criao de aspectos abstratos,
semelhantemente a uma classe abstrata em Java, porm, alm de mtodos abstratos o aspecto
tambm pode possuir conjuntos de juno abstratos. Um conjunto de juno abstrato no tem
conhecimento dos pontos de juno que sero afetados, pois esses pontos devem ser
informados em um aspecto concreto que especializar o aspecto abstrato. Como um adendo
pode ser definido sobre um conjunto de juno abstrato, pode-se implementar um
comportamento transversal no aspecto abstrato sem saber de antemo quais so os pontos de
juno, e conseqentemente, qual o cdigo-base em que esse comportamento ir atuar.
Aspectos abstratos so a base do desenvolvimento orientado ao reso, e conseqentemente,
do desenvolvimento de frameworks orientados a aspectos.
Na Figura 2.4 mostrado um aspecto abstrato cuja tarefa estabelecer conexes com
o banco de dados. H um conjunto de juno abstrato denominado doConnection() e um
adendo do tipo after() que atua sobre ele. O mtodo ConnectDB() sempre ser chamado
aps (after) os pontos de juno que sero informados no aspecto concreto que especializar
esse aspecto abstrato. Assim, um aspecto concreto deve ser criado para especializar esse
aspecto abstrato e concretizar o conjunto de juno doConnection() com algum ponto de
juno em que a conexo deve ser estabelecida, como est sendo exibido na Figura 2.5. Esse
aspect DisplayUpdating
{ pointcut move():
call(void Line.set*(Point)) || call(void Point.set*(int));

after() returning: () {
Display.updating();
}
}


12
aspecto concreto indica que sempre que um mtodo init() for executado a conexo deve ser
estabelecida.

Figura 2.4 Aspecto Abstrato

Figura 2.5 Aspecto Concreto
2.2.2 Interfaces de Lntrecorte
Um ponto importante com relao a mdulos de um sistema sua interface. Uma
interface uma descrio ou receita de como o mdulo interage com o resto do sistema
(Meyer, 1997 apud (Chavez et al., 2005))
2
(Mezini e Ostermann, 2003 apud (Chavez et al.,
2005))
3
. Na linguagem de programao Java, h um construtor especfico para a
implementao de interfaces, o que permite expor um subconjunto do comportamento de um
mdulo para outros mdulos. No caso de mdulos aspectuais existe o conceito de interface
de entrecorte (crosscutting interface), que consiste em um conjunto nomeado de detalhes de
entrecorte (crosscutting features) (Chavez et al., 2005). Detalhes de entrecorte so
comportamentos que podem afetar estaticamente ou dinamicamente algum cdigo-base
(Chavez, 2004).
No caso da linguagem AspectJ, uma interface de entrecorte representada por um
conjunto de juno juntamente com os pontos de juno que devem ser expostos do cdigo-
base. Diferentemente da linguagem Java, em AspectJ no h um construtor de linguagem
especfico para implementar uma interface de entrecorte. Assim, nas implementaes mais
convencionais de aspectos, esse tipo de interface encontra-se implementado no mesmo
mdulo (aspecto) do comportamento transversal, como pode ser visto na Figura 2.3. A
interface de entrecorte consiste no conjunto de juno move() e nas especificaes dos

2
Meyer, B. Object-Oriented Software Construction. 2a edio. Prentice Hall, 1997.
3
Mezini, M., Ostermann, K. Conquering Aspects with Caesar. Proceedings of the Aspect Oriented Software
Development Conference (AOSD03), pp, 90-99, 2003.
public aspect AspectConnection extends AbstractAspectConnection
{
pointcut doConnection(): execution (void *.init(..));
}
public abstract aspect AbstractAspectConnection
{
...
abstract pointcut doConnection();

after() : doConnection()
{
ConnectDB();
}
}
13
pontos de juno. Essa interface de entrecorte est implementada no mesmo aspecto que
possui o comportamento transversal que atua sobre ela.
H propostas que fornecem diretrizes de como implementar interfaces de entrecorte
em AspectJ separadamente do comportamento transversal que deve atuar sobre elas (Griswold
et al., 2005). Consiste em uma forma de reorganizar o cdigo, criando aspectos que
encapsulam apenas os conjuntos de juno e outros aspectos que encapsulam apenas adendos
que atuam naqueles naqueles conjuntos de juno.
2.3 IRAMLWORKS DL SOI1WARL ORILN1ADOS A OBJL1OS
De acordo com Fayad et al. (1999), frameworks orientados a objetos so solues de software
que tm o objetivo de apoiar o desenvolvimento de aplicaes em domnios especficos. O
objetivo principal a reutilizao de projeto e cdigo em um esforo para aumentar a
velocidade do desenvolvimento e a qualidade das aplicaes desenvolvidas.
A fase de uso e aprendizagem de um framework tambm conhecida como fase de
instanciao ou fase de desenvolvimento de aplicaes (Fayad et al., 1999). Nela, um ou mais
frameworks podem ser utilizados na construo de aplicaes especficas. No fim do projeto
de cada aplicao, novas classes podem ser acrescentadas para atender aos requisitos
especficos da aplicao.
Fayad et al. (1999) tambm comentam que um ponto importante durante a construo
de um framework identificar as partes fixas (frozen spots) e variveis (hot spots) de um
domnio de aplicao. Diferentes aplicaes em um mesmo domnio so distinguidas por uma
ou mais partes variveis. Elas representam as partes do framework que so especficas de
sistemas individuais. As partes variveis so projetadas para serem genricas e podem ser
adaptadas s necessidades da aplicao. Partes fixas definem a arquitetura geral de um
sistema de software seus componentes bsicos e os relacionamentos entre eles. As partes
fixas so usadas sem nenhuma modificao em todas as instanciaes de um framework de
aplicao.
Uma propriedade importante de um framework a inverso de controle (Johnson,
1997). No reso tradicional de componentes ou bibliotecas, desenvolve-se a aplicao
especfica com chamadas aos componentes que se deseja reutilizar. Assim, a responsabilidade
pelas chamadas e pelo fluxo de controle do programa do desenvolvedor de aplicaes. J em
um framework, o programa principal reusado, ficando a cargo do desenvolvedor de
aplicaes apenas a tarefa de concretizar alguns mtodos abstratos que so chamados pelo
cdigo do framework, e no por ele. Essa inverso tambm conhecida por principio de

14
Hollywood no ligue para ns, ns ligaremos para voc. Assim, o framework determina o
fluxo de controle do programa e sua estrutura geral.
Uma classificao que pode ser feita dos frameworks quanto ao tipo de reso. Eles
podem ser: caixa branca (White box), caixa cinza (gray box) e caixa preta (black box) (Yassin
& Fayad, 2000). O comportamento especfico de um framework de aplicao geralmente
definido adicionando-se mtodos s subclasses de uma ou mais de suas classes. No
framework caixa branca o reso provido por herana, ou seja, o usurio deve criar
subclasses das classes abstratas contidas no framework para criar aplicaes especficas. Para
tal, ele deve entender detalhes de como o framework funciona para poder us-lo. No
framework caixa preta o reso por composio, ou seja, o usurio combina diversas classes
concretas existentes no framework para obter a aplicao desejada. Assim, ele deve entender
apenas a interface para poder us-lo. J no framework caixa cinza h uma mistura entre os
frameworks caixa branca e caixa preta. Assim, o reso obtido por meio de herana, por
ligao dinmica e tambm pelas interfaces de definio.
Um framework caixa branca mais fcil de projetar, pois no h necessidade de
prever todas as alternativas de implementao possveis, o que ocorre no framework caixa
preta. No entanto, o framework caixa preta mais fcil de usar, pois basta escolher a
implementao desejada, ao invs de fornecer a implementao completa, como o caso do
caixa branca. Todos os FTs desenvolvidos no contexto desta tese so caixa-branca.
Fayad et al. (1999) comentam que o desenvolvimento de um framework similar ao
desenvolvimento da maioria de qualquer software reutilizvel. Inicialmente feita anlise de
domnio, seguida do projeto de um framework que implemente os exemplos coletados durante
a anlise de domnio. O framework ento utilizado para construir outras aplicaes, as quais
fornecero indicaes de seus pontos fracos. Ele ento modificado, melhorado e submetido
a novas utilizaes, num processo iterativo. As experincias na aplicao do framework,
possivelmente a novos exemplos, servem de entrada para a prxima iterao do framework,
que prossegue at que os desenvolvedores o considerem acabado e decidam por sua liberao.
Segundo Pree and Koshimies (2000), o termo framework no impe limite mximo
ao nmero de classes que um framework pode possuir. Dessa forma, eles podem variar de
uma ou um conjunto simples de classes a conjuntos grandes de classes complexas. A
tendncia tm sido o desenvolvimento de grandes frameworks que encapsulam solues
genricas para um determinado domnio de aplicao, como: sistemas de fabricao, bancos,
sistemas de sade e sistemas de controle de processo. Vrios autores (Sparks, 1996 apud
15
(Pree, 2000))
4
, (Bosch, 1998 apud (Pree, 2000))
5
, (Casais, 1995 apud (Pree, 2000))
6

discutem alguns problemas associados a frameworks complexos. Segundo esses autores, os
seguintes problemas ocorrem com grandes frameworks:
O projeto de um framework difcil. Em conseqncia da complexidade e tamanho
dos frameworks de aplicao, e da dificuldade de compreenso do processo de projeto,
frameworks so geralmente projetados iterativamente, exigindo reestruturao
substancial de inmeras classes e ciclos de desenvolvimento;
O processo de reso difcil. Convencionalmente, um framework consiste em um
conjunto de classes bsicas de um domnio de aplicao. Assim, o responsvel pelo
reso deve compreender a arquitetura bsica de um tipo de aplicao particular para
ser capaz de especializar o framework;
A combinao de frameworks difcil. Freqentemente um framework assume o
controle da aplicao. Combinar dois ou mais frameworks que fazem isso, sem
quebrar a integridade deles muito difcil.
A presena de classes desnecessrias nas aplicaes instanciadas. Em geral, as
aplicaes instanciadas de um framework levam consigo todas as classes do
framework, independentemente se todas elas so usadas ou no.
Pree e Koshimies (2000) sugerem que a razo desses problemas a idia de que um
framework um esqueleto de uma aplicao complexa. Conseqentemente, um framework se
torna uma grande coleo de classes altamente acopladas que dificulta a modularizao e
dificulta a integrao com frameworks similares. Muitos autores comentam que a soluo
para isso criar verses caixa-preta dos frameworks, que so especializados por composio e
no por herana. Embora isso facilite o reso do framework, restringe sua adaptabilidade e os
problemas de projeto e combinao de frameworks podem permanecer.
Para Pree e Koshimies (2000) a soluo o desenvolvimento de framelets, que so
frameworks pequenos, com menos de dez classes, que no assumem o controle da aplicao e
tm uma interface claramente definida. Assim como qualquer framework, um framelet pode
ser especializado por meio de herana e composio. Pree defende a idia de que uma famlia
de framelets relacionados de um determinado domnio uma alternativa ao uso de um grande

4
Sparks S, Benner K, Faris C. Managing Object-Oriented Framework Reuse. Computer. 1996; Vol. 29, No. 9.

5
Bosch, J, Mattsson, M., and Fayad, M. Framework Problems, Causes, and Solutions, CACM, 1998.

6
Casais E. An Experiment in Framework Development. Theory and Practice of Object Systems 1, 4, 269-280,
1995.


16
e complexo framework. Quando um framelet utilizado em uma aplicao, o fluxo de
controle principal da aplicao, mas quando o fluxo atinge os pontos em que o framelet est
sendo utilizado, o fluxo de controle passa a ser deles, isto , eles tambm possuem o princpio
de Hollywood, propriedade dos frameworks caixa branca.
Um exemplo de um framelet apresentado por Pree e Koshimies (2000) uma caixa de
listagem (list box) que pode ser usada durante a construo de interfaces grficas. Essa caixa
de listagem, ao contrrio da maioria dos frameworks grficos existentes, j possui
implementadas as iteraes entre os botes para se adicionar, remover e alterar dados.
Em uma linha de pesquisa parecida com a dos framelets, alguns frameworks um pouco
maiores foram criados com o objetivo de encapsular um determinado interesse. Exemplos de
frameworks orientados a objetos (FOOs) de persistncia que se enquadram nessa categoria
so: Hibernate (2006), Cayenne (2006) e OJB (2006).
Outros autores que compartilham a idia de Pree e Koshimies (2000) em substituir
grandes frameworks por um conjunto de componentes menores que podem ser combinados
so Batory et al. (2000). Porm, para esses autores, a melhor alternativa a utilizao de
linhas de produtos (Parnas, 1976 apud (Batory et al., 2000))
7
ao invs de grandes frameworks.
2.3.J Modelagem de Irameworks com o Perfil UML-I
UML-F um perfil UML criado para a modelagem de frameworks orientados a objetos
(Fontoura et al., 2002). Ele contm elementos notacionais que descrevem a semntica
fundamental de conceitos clssicos em frameworks OO. Na UML-F, tanto os esteretipos
quanto as etiquetas valoradas da UML foram agrupados em um nico elemento chamado de
etiqueta UML-F. A representao dessa etiqueta a mesma de um esteretipo clssico da
UML, entretanto pode possuir um valor, assim como as etiquetas valoradas. Essas etiquetas
so divididas em quatro categorias. A Tabela 2.1 mostra algumas das etiquetas propostas
dentro de cada uma de suas categorias.
A categoria Etiquetas de Modelagem de Framework possui etiquetas que visam a
auxiliar a documentao do framework, principalmente para o desenvolvedor de aplicao.
Essas etiquetas permitem identificar quais classes so do framework e quais so da aplicao,
quais classes e mtodos so fixos e quais podem ser adaptados. A categoria Etiquetas para
Princpios Essenciais de Construo de Frameworks OO possui etiquetas que representam
dois papis impostos pela utilizao do padro de projeto Mtodo Gabarito (Template
Method): os mtodos gabarito e os mtodos gancho (hook method).

7
PARNAS, D.L. On The Design and Development of Program Families. IEEE Transactions on Software
Engineering, March, 1976.
17
Tabela 2.1 Etiquetas da UML-F
1-Etiquetas de Modelagem de Framework
Etiqueta Descrio
<<application>> O elemento pertence aplicao e no ao framework
<<framework>> O elemento pertence ao framework e no aplicao.
<<utility>> O elemento pertence a uma classe de biblioteca.
<<fixed>> O elemento fixo, isto , nenhuma alterao pode ser feita nele.
<<adapt-static>> O elemento deve ser modificado durante o projeto, mas durante a execuo ele fixo.
Geralmente essa adaptao consiste em especializar o elemento.
<<adapt-dyn>> O elemento pode ser modificado em tempo de execuo.
2-Etiquetas para Princpios Essenciais de Construo de Frameworks OO
Etiqueta Descrio
<<template>> O mtodo um mtodo gabarito ou a classe possui um mtodo gabarito.
<<hook>> A existncia desta etiqueta denota que o mtodo um mtodo gancho (hook)
3-Etiquetas para Padres utilizados em Frameworks
Etiqueta Descrio
<<PatternName-ClassName>> Onde: PatternName deve ser substitudo pelo nome do padro que
est sendo utilizado e ClassName pelo nome da classe que determina
um papel dentro do padro. A existncia dessa etiqueta denota a
utilizao de um determinado padro de projeto e tambm denota
quais so as classes que assumem os papis definidos pelo padro.
<<PatternName-InterfaceName>> O mesmo que acima, mas para interfaces.
<<PatternName-methodName>> O mesmo que acima, mas para mtodos.
<<PatternName-associationLabel>> O mesmo que acima, mas para rtulos de relacionamentos.
<<PatternName-attributeName>> O mesmo que acima, mas para atributos.

A categoria Etiquetas para Padres Utilizados em Frameworks agrupa etiquetas que
visam a demonstrar os padres de projeto utilizados na estrutura do framework. Elas devem
ser utilizadas para demonstrar os papis do padro que so assumidos pelas classes, atributos
ou mtodos do framework.
Um ponto importante a ser notado que Fontoura (2002) conseguiu agrupar em
algumas etiquetas os conceitos bsicos de frameworks orientados a objetos. O conceito mais
importante relacionado construo e instanciao de um framework identificar os pontos
fixos (frozen spots) e os pontos variveis (hot spots) de um domnio de aplicao e as
etiquetas UML-F so destinadas a esse fim.
2.3.2 Linhas de Produtos e Irameworks Orientados a Objetos
Uma linha de produtos uma forma de se construir software rapidamente compondo
caractersticas
8
(features) de um domnio especfico (Weiss e Lai, 1999; Gomma, 2004).
Caractersticas so abstraes de projeto e cdigo que representam requisitos ou
variabilidades de um domnio. Podem ser opcionais, alternativas ou obrigatrias e podem ser
acopladas em uma base, ou mesmo em outras caractersticas para a construo de aplicaes
de um determinado domnio. H vrias abordagens que empregam o uso de caractersticas
como incrementos ou refinamentos sobre outra caracterstica ou programa existente. Algumas

8
A palavra caracterstica no est sendo utilizada no texto com seu significado convencional da Lngua
Portuguesa.

18
dessas abordagens so: GenVoca (Batory e Malley, 1992 apud (Mezini e Ostermann, 2004))
9
,
mixin-layers (Smaragdakis e Batory, 1998 apud (Mezini e Ostermann, 2004))
10
, delegation
layers (Ostermann, 2002 apud (Mezini e Ostermann, 2004))
11
e AHEAD (Batory et al., 2003
apud (Mezini e Ostermann, 2004)
12
.O objetivo dessa nova linha de pesquisa implementar
caractersticas que envolvem interesses transversais com aspectos para facilitar o acoplamento
e desacoplamento dessas caractersticas.
Frameworks so ferramentas que podem ser usadas para a implementao de linhas de
produtos (Batory et al., 2000), pois cada aplicao instanciada do framework pode ser
caracterizada com um membro da linha com caractersticas distintas. Entretanto, algumas
pesquisas mostram que a utilizao de grandes frameworks em linhas de produtos gera
problemas de duplicao de cdigo nos membros da linha e outros problemas relacionados
(Batory et al., 2000). Para solucionar os problemas Batory et al. (2000) propuseram uma
metodologia de projeto, chamada GenVoca, que consiste em dividir a arquitetura do
framework, e tambm de suas aplicaes, em camadas (mixin-layers), em que cada camada
consiste em um conjunto de classes que colaboram entre si. Essas camadas so blocos de
construo para o desenvolvimento de aplicaes e representam as caractersticas disponveis
do domnio. Dessa forma, as entidades principais (first class entites) na programao
orientada a caractersticas so as caractersticas um nvel de abstrao mais alto do que
classes. Cada camada realiza refinamentos na camada anterior adicionando mtodos e
atributos. Assim, aplicaes complexas podem ser desenvolvidas como uma composio de
poucos refinamentos, ao invs de centenas de milhares de refinamentos.
Um ponto importante do trabalho de Batory et al. (2006) a idia de que a estrutura
do framework tambm pode ser decomposta em caractersticas. Isso interessante porque
tradicionalmente, quando uma aplicao instanciada de um framework, ela contm em sua
arquitetura todas as classes do framework, inclusive aquelas que no foram escolhidas como
variabilidades da aplicao um problema conhecido como overfeaturing (Codenie et al.,
1997 apud (Batory et al., 2000))
13
. Quando um framework utilizado de forma tradicional
para a gerao de vrios membros da linha de produtos, haver muita repetio de classes sem

9
BATORY, D., MALLEY, S. The Design and Implementation of Hierarchical Software Systems with Reusable
Componentes. ACM Transactions on Software Engineering and Methodology, 1(4):355-398, 1992.
10
SMARAGDAKIS, Y., BATORY, D. Implementing Layered Designs With Mixin-Layers. In Proceedings of
ECOOP98, LNCS 1445, pages 550-570, 1998.
11
OSTERMANN, K. Dynamically Composable Collaborations with Delegation Layers. In: Proceedings of
ECOOP02. LNCS 2374, pages 89-110. Springer, 2002.
12
BATORY, D., SARVELA, J.N., RAUSCHMAYER, A. Scaling step-wise refinement. In: Proceedings of
International Conference on Software Engineering (ICSE03), 2003.
13
CODENIE, W., HONDT, K., STEYAERT, P., VERCAMMEN, A. From Custom Applications to Domain-
Specific Frameworks. Communications of the ACM, 40(10), October, 1997.
19
utilizao em todos os membros. Como a estratgia apresentada pelo autor permite a
montagem tambm do framework, as variabilidades que no sero necessrias na aplicao
no so escolhidas nessa primeira etapa.
A programao orientada a caractersticas atualmente reconhecida como melhor do
que a tecnologia de frameworks porque trabalha com camadas que possuem duas vantagens
importantes (Mezini e Ostermann, 2004). A primeira que cada camada encapsula vrias
abstraes referentes a uma determinada caracterstica do domnio em uma unidade modular
nica, que do contrrio estariam espalhadas por vrios mdulos do sistema. FeatureC++
(FeatureC++ WebSite, 2006), por exemplo, uma extenso da linguagem C++ que pode ser
usada para a definio e refinamento de caractersticas. A segunda vantagem que essas
camadas possuem abstraes definidas em termos de abstraes de uma parte base, o que
permite que essas camadas possam ser conectadas umas nas outras sem necessidade de
programao extra, como ocorre durante a instanciao dos frameworks convencionais.
2.4 IRAMLWORKS NO CON1LX1O DA POA
Depois do surgimento da POA e da disseminao da linguagem AspectJ (Kiczales et al.,
2001), vrias pesquisas comearam a ser conduzidas nas mais variadas linhas de pesquisa.
Uma dessas linhas concentra-se no reso de interesses transversais durante o desenvolvimento
de uma nova aplicao. Assim, pesquisadores investigam como que a POA pode ser utilizada
para implementar interesses transversais de forma genrica. Apesar da similaridade entre os
trabalhos encontrados nessa linha de pesquisa, no h um consenso sobre o termo utilizado
para designar esse tipo de implementao. A seguir so mostrados os principais trabalhos
encontrados na literatura e o termo original utilizado por cada um dos autores.
O primeiro autor a propor um framework orientado a aspectos foi Constantinides
(Constantinides et al., 2000). Seu framework encapsula o interesse transversal de
concorrncia e no implementado com uma linguagem orientada a aspectos. No ano
seguinte, Vanhaute et al. (2001) apresentaram um framework de aspectos de segurana e
tambm algumas diretrizes, ainda bastante preliminares, de como construir frameworks
utilizando a linguagem AspectJ. Depois disso vrios outros frameworks foram desenvolvidos.
Pode-se encontrar propostas de frameworks para o interesse persistncia (Rashid and
Chitchyan, 2003; Couto et al., 2005; Camargo et al., 2003; Soares et al., 2002; Rausch et al.,
2003), segurana (Chen e Huang, 2005; Zubairov et al., 2005), distribuio (Soares et al.,
2002; concorrncia (Soares, 2004), criptografia (Zhang et al., 2004) e de alguns outros
interesses (Mortensen e Ghosh, 2006a; Mortensen e Ghosh, 2006b). O objetivo dessa linha de

20
pesquisa permitir que a implementao e o projeto do interesse transversal possa ser reusado
durante o desenvolvimento de uma nova aplicao.
Embora tambm tenham surgido pesquisas utilizando aspectos em frameworks de
aplicao orientados a objetos (Pinto et al., 2001a; Pinto et al., 2001b; Pinto et al., 2002;
Hanenberg et al., 2004), a maior parte se concentrou em frameworks de um nico interesse.
possvel tambm encontrar atualmente propostas que visam a facilitar o processo de reso de
frameworks desse tipo (Mendona et al., 2005).
2.4.J Irameworks de Persistncia no Contexto da POA
Um framework de persistncia baseado em aspectos foi desenvolvido por Rashid e Chitchyan
(2003). O objetivo dos autores foi averiguar se o interesse de persistncia pode ser acoplado
apenas no final do desenvolvimento de uma aplicao, sem que essa aplicao seja
desenvolvida com conscincia da persistncia. Os autores concluram que o armazenamento e
a atualizao de dados podem ser completamente aspectualizados, isto , podem ser
adicionados depois que a aplicao est pronta, mas o mesmo no ocorre com a remoo e
com as operaes de consulta. Isso acontece porque o armazenamento e a atualizao
possuem pontos de juno explcitos no cdigo-fonte que podem ser associados a essas
operaes de persistncia. Por exemplo, pode-se definir a estratgia que quando a instncia de
um objeto criada, o aspecto entrecorta a execuo do construtor e armazena esse objeto em
um banco de dados. Da mesma forma, a atualizao de dados pode ocorrer sempre que algum
mtodo set*() chamado para algum dos objetos da aplicao.
Entretanto, a remoo de objetos de um banco de dados no pode ser associada com
algum ponto de juno. No possvel, por exemplo, entrecortar a execuo do mecanismo de
coleta de lixo do Java quando ele retira um objeto da memria. E mesmo se isso fosse
possvel, nada garante que aquele objeto deveria se eliminado do banco de dados naquele
momento. O mesmo ocorre para as consultas deve haver chamadas explcitas a operaes de
banco de dados quando, de acordo com o algoritmo da aplicao, necessrio realizar algum
tipo de consulta.
Portanto, a persistncia no pode ser completamente negligenciada durante o
desenvolvimento de uma aplicao e acoplada apenas no final do desenvolvimento. O
engenheiro de software precisa estar ciente dos locais do cdigo em que a aplicao precisa
remover e consultar dados.
No framework de persistncia apresentado por Rashid e Chitchyan (2003) no houve
preocupao em generalizar certos pontos do cdigo dos adendos, dificultando o reso. O
objetivo principal do estudo realizado por eles no foi criar um framework que pudesse ser
21
reusado em diversas aplicaes, apesar de utilizarem o termo framework. Os autores
tambm no implementam sub-interesses, como, por exemplo, memria auxiliar (caching) e
repositrio de conexes (pooling) como aspectos, o que pode auxiliar na modularizao.
Um outro trabalho que envolve a criao de aspectos genricos foi feito por Soares
(Soares, 2004; Soares et al., 2002). Esse autor desenvolveu trs frameworks de aspectos, um
de persistncia, um de distribuio e um de concorrncia. Os trs frameworks foram obtidos
reimplementando-se com POA os interesses de persistncia, distribuio e concorrncia de
um sistema orientado a objetos chamado Health Watcher.
Um ponto interessante desse trabalho (Soares, 2004) a possibilidade de utilizar uma
estratgia de gerenciamento de dados no persistentes enquanto a aplicao desenvolvida.
Assim, quando testes precisam ser feitos, pode-se utilizar essa estratgia de armazenamento
de dados em memria voltil. No final do desenvolvimento, pode-se substituir a estratgia
voltil pela persistente. Outro ponto importante da abordagem de Soares (2004) o apoio
automatizado que foi criado para o acoplamento automtico dos frameworks com o cdigo-
base. O autor desenvolveu um plug-in para o ambiente Eclipse que facilita o acoplamento dos
frameworks com o cdigo-base. O framework de Soares (2004) inclui aspectos, classes
auxiliares e interfaces que cuidam dos seguintes interesses: conexo com o banco de dados,
controle de transaes, carregamento de objetos, caching e sincronizao do estado de objetos
com entidades do banco de dados.
Uma limitao do trabalho de Soares (2004) que o framework s pode ser utilizado
em aplicaes que tiverem a mesma arquitetura do sistema Health Watcher, o que limita as
possibilidades de reso do framework. Alm disso, no h utilizao de algum mecanismo
para a gerao automtica de cdigo SQL, o que faz com que declaraes SQL tenham que
ser implementadas de forma fixa no frameowork.
Couto et al. (2005) tambm apresentam um framework orientado por aspectos de
persistncia que foi dividido nos sub-interesses controle de conexes, controle de transaes e
controle de sincronizao de objetos. O ponto forte do trabalho dos autores o apoio
automatizado para realizar o acoplamento do framework com uma aplicao. Entretanto, a
estratgia utilizada para a gerao dos aspectos faz com que um aspecto seja criado para cada
classe de aplicao persistente. Dependendo do tamanho da aplicao pode haver uma
proliferao de aspectos, o que pode dificultar operaes de manuteno.
Outra desvantagem do framework proposto por Couto o fato de no disponibilizar
recursos para a recuperao automtica de dados do banco. O arcabouo no constri
nenhuma consulta SQL para que a recuperao de dados possa ser feita. Assim, cabe ao

22
programador implementar tais consultas. Alm disso, o framework no foi desenvolvido
segundo algum padro de projeto, como, por exemplo, o Camada de Persistncia (Yoder et
al., 1998).
2.4.2 Irameworks de Segurana no Contexto da POA
Um framework orientado a aspectos que trata apenas do requisito no-funcional segurana
proposto por Vanhaute et al. (2001). O autor comenta que o sub-interesse de controle de
acesso, que faz parte do interesse de segurana, possui os mesmos requisitos para a maioria
das aplicaes, porm, possui algumas polticas especficas da aplicao, como por exemplo,
o usurio que acessou o sistema e os recursos disponveis. Trs conceitos so importantes em
um sistema de controle de acesso: a entidade a ser autenticada, os recursos que sero
disponibilizados e o ponto de acesso entre a entidade e os recursos.
Na Figura 2.6 apresentada a parte do controle de acesso do framework de segurana.
Utilizam-se trs aspectos abstratos: Authorization, Authentication e
Identification. As setas tracejadas indicam os conjuntos de juno abstratos que devem
ser implementados por aspectos concretos para indicar os pontos de juno do cdigo-base
que devem ser entrecortados.
A estrutura do framework apresentada na Figura 2.7. O Ncleo do Framework
contm aspectos abstratos, como aqueles mostrados na Figura 2.6, e a parte Polticas consiste
em conjuntos de juno abstratos. Para cada mecanismo abstrato h vrias implementaes
concretas disponveis. Para usar o framework, o desenvolvedor deve definir uma poltica
concreta de acordo com as necessidades da aplicao.
O maior problema encontrado pelos autores durante o desenvolvimento do framework
foram as definies dos conjuntos de juno. Como essas definies so estticas, s podem
ser referenciadas e estendidas estaticamente. Essa restrio impossibilita isolar uma definio
de conjunto de juno abstrata em um construtor separado e confiar na delegao para
selecionar a verso concreta. Os autores sugerem que uma forma de resolver este problema
seria fornecer um processo de composio mais aberto, em que as definies dos conjuntos de
juno pudessem ser resultado de uma avaliao funcional da estrutura da aplicao. O
framework apresentado pelos autores interessante, porm poucos detalhes so fornecidos
que permitem uma anlise mais profunda da sua arquitetura.
Zhang et al., (2004) apresentam uma biblioteca de aspectos genricos de segurana
implementada em AspectJ, chamada JSAL (Java Security Aspect Library), que consiste em
quatro interesses: Autenticao, Autorizao (tambm conhecido como Controle de Acesso),
Criptografia e Auditoria. Segundo os autores os interesses so independentes e podem ser
23
utilizados em uma aplicao sem a presena dos outros. Alm disso, eles tambm so
genricos e podem ser adicionalmente especializados. Por exemplo, o aspecto genrico de
criptografia pode ser refinado em aspectos especializados de algoritmos de criptografia.

Figura 2.6 Framework de Segurana Orientado a Aspectos (Vanhaute et al., 2001)

Figura 2.7 - Estrutura do Framework (Vanhaute et al., 2001)
abstract aspect Identification
{ Subject subject = null;
public Subject doLogin()
{
// login
}
}
abstract aspect Authentication of eachcflowroot(Authentication.accessPoint)
{
private Subject subject;

abstract pointcut accessPoint;

before(Object caller):accessPoint() && hasAspect(Identification)
{
Identification id = Identification.aspectOf(caller);
if (id.subject = null)
{
id.doLogin();
}

subject = id.subject;
}

public Subject getSubject()
{
return subject;
}
}
abstract aspect Authorization
{

abstract pointcut checkedMethods();

before():checkedMethods()
{ Authentication au = Authentication.aspectOf();
Subject subject = au.getSubject();
// cdigo para checagem do acessso
} }
Polticas
Abstract
Mechanism
Abstract
Mechanism
Mecanismo
Abstrato
Concrete
Mechanism
Concrete
Mechanism
Mecanismo
Concreto

Ncleo
do lramework
Framework de
Segurana
Polticas
da Aplicaao
Aplicaao

24
Na Figura 2.8 mostrado o aspecto genrico de criptografia pertencente biblioteca
JASL. H dois conjuntos de juno abstratos que devem ser concretizados pelo engenheiro de
aplicao. O primeiro deve ser concretizado informando mtodos do cdigo-base que
possuem como parmetro uma String que deve ser criptografada, e o segundo deve ser um
mtodo cujo parmetro uma String que deve ser descriptografada.

Figura 2.8 Aspecto Genrico de Criptografia da Biblioteca JASL
A biblioteca JASL interessante porque agrupa sub-interesses de apenas um interesse
maior, no caso, segurana. A evoluo dessa biblioteca pode auxiliar bastante o
desenvolvimento de aplicaes que necessitam de segurana. Entretanto, algumas limitaes
podem ser percebidas na implementao mostrada pelos autores. Os conjuntos de juno
abstratos possuem parmetros do tipo String. Isso obriga o engenheiro de software a
encontrar no cdigo-base um ponto de juno que seja a chamada ou a execuo de um
mtodo cujo nico parmetro seja uma String e que esse parmetro seja o dado que deve ser
criptografado. Essa estratgia de implementao limita a reusabilidade da biblioteca, pois no
se pode garantir que o cdigo-base sempre ter um ponto de juno nesse formato.
Em sua tese de doutorado, De Win
14
(De Win, 2004 apud (Zubairov et al., 2005))
procurou estudar o problema da modularizao do interesse de segurana para aplicaes. A

14
De Win, B. Engineering Application-Level Security through Aspect-Oriented Software
Development. Ph.D. Thesis, Departamento de Cincia da Computao, K.U, Leuven,
Blgica, Maro, 2004.

public abstract aspect AbstractDESAspect {

public abstract pointcut encryptOperations(String msg);
public abstract pointcut decryptOperations(String msg);

public void around(String msg): encryptOperations(msg) {
//Create encrypter class
DesCipher enc = new DesCipher();
enc.savekey("Deskey");
//Encrypt
String encryptedMsg = enc.encrypt(msg);
proceed(encryptedMsg);
}

public void around(String msg): decryptOperations(msg) {
//Create encrypter class
DesCipher enc2=new DesCipher("Deskey");
//Decrypt
String decryptedMsg = enc2.decrypt(msg);
proceed(decryptedMsg);
}
25
discusso conduzida com o objetivo de identificar como as tcnicas orientadas a aspectos
podem otimizar a modularizao de requisitos de segurana no nvel de aplicaes. A tese
contm discusses sobre abordagens de interceptao (interceptors) e abordagens de
composio para se modularizar a segurana em um servidor de FTP e uma aplicao de
gerenciamento de informao pessoal. Esse autor conclui que o interesse de segurana
altamente transversal.
Zubairov cita que as concluses de De Win(2004) no podem ser generalizadas
porque h muita dependncia com a arquitetura das aplicaes utilizadas (Zubairov, et al.,
2005). A arquitetura do sistema utilizado no estudo de caso conduzido por Zubairov
diferente da arquitetura dos sistemas desenvolvidos por De Win, e isso faz com que algumas
concluses no possam ser generalizadas para o interesse de segurana, de forma geral.
Chen e Huang (2005) realizaram a implementao dos interesses de autenticao e
controle de acesso em AspectJ com o objetivo de torn-los reusveis para aplicaes Web
baseadas no padro MVC e no frameworks struts. Os autores comentam que h vrios nveis
de controle de acesso: nvel de classes, nvel de funes (mtodos) e nvel de atributos. No
nvel de atributos, em que a granularidade a mais fina de todas, pode-se determinar quais
atributos de uma classe podem ou no ser acessados por determinados usurios. Eles no
utilizam a API Java JAAS porque a utilizao dessa biblioteca faz com que vrias chamadas
sejam colocadas em vrios locais do cdigo, causando espalhamento e entrelaamento de
cdigo de diferentes interesses. Alm disso, JAAS fornece um controle de acesso muito
simples para funes. Na Figura 2.9 mostrado o aspecto de Autenticao apresentado pelos
autores. Este aspecto tem o objetivo de verificar se o usurio passou pela checagem de
identidade ou deve ser redirecionado para uma pgina de autenticao.
Um ponto que merece destaque na implementao de Chen e Huang (2005) que o
conjunto de juno abstrato pc() definido com parmetros. Quando isso ocorre, o adendo
que atua sobre ele tambm deve ser definido com parmetros. Isso prejudica a reusabilidade
do aspecto, pois nada garante que o cdigo-base possuir um ponto de juno com
parmetros. Uma outra forma de capturar os parmetros do contexto de execuo deveria ser
fornecida.
No aspecto de controle de acesso, que pode ser visto na Figura 2.10, o conjunto de
juno pc() tambm implementado com parmetros, prejudicando o reso. Alm disso, a
implementao do mtodo constraint(), que responsvel por definir uma restrio de
acesso, deixado para o aspecto concreto. Embora isso deixe o cdigo bastante flexvel,
dificulta um pouco o processo de reso do framework.

26
Mortensen e Ghosh (2006a) (2006b) tm como objetivo desenvolver uma biblioteca
de aspectos em AspectC++ que sejam reusveis. O processo utilizado pelos autores para a
criao da biblioteca a refatorao (refactoring) dos interesses transversais de algumas
aplicaes. O domnio de aplicao que os autores trabalham de projeto de chips VLSI. Eles
possuem algumas aplicaes que utilizam o framework orientado a objetos VLSI CAD, um
framework desenvolvido por laboratrios da Hewlett Packard. At o presente momento, os
autores identificaram quatro interesses transversais que foram implementados como aspectos
genricos e adicionados na biblioteca de aspectos. Os interesses implementados como
aspectos foram: Depurao de Programas (Debug), temporizador, garantia de polticas e
memria auxiliar.

Figura 2.9 Aspecto de Autenticao
2.4.3 Irameworks de Aplicao no Contexto da POA
Pinto e outros (2001a; 2001b, 2002) apresentam um framework de aplicao orientado a
aspectos, totalmente desenvolvido em Java, para o desenvolvimento de ambientes virtuais de
colaborao (AVC). Segundo os autores a utilizao da POA facilita a configurao, a
public abstract aspect Authentication {

abstract pointcut pc(..); //arguments omitted
abstract protected String forwardPage();
abstract protected Boolean isAuthenticated(HttpServletRequest request);

private ActionForward forwardTo (ActionMapping mapping, String
signonPage)
{
return mapping.findForward(signOnPage);
}

ActionForward around(..):pc(..)
{
if (isAuthenticated(request))
return proceed(mapping,form,request,response);
else
return forwardTo(mapping, forwardPage());
}
}
}

public abstract aspect PWD extends Authentication {

protected String forwardPage() {
return globalSignOn;
}
protected Boolean isAuthenticated(HttpServletRequest request)
{ }
}

public abstract aspect DC extends Authentication {
protected String forwardPage() {
return RequireDigitalCertificate;
}
protected Boolean isAuthenticated(HttpServletRequest request) { }
}

27
extenso, a evoluo e a adaptao desses softwares, bem como das aplicaes instanciadas.
O desenvolvimento desse framework teve como base a anlise de vrios AVCs, e identificou-
se que os componentes: usurio, sala, documento e ferramenta, e os aspectos: persistncia,
autenticao e vises mltiplas esto sempre presentes nesse tipo de software.
Em conseqncia da grande diversidade e da grande quantidade de comportamentos
diferentes, os aspectos so classificados em tipos dentro do framework: orientado ao
ambiente, orientado ao usurio, orientado ao tipo ou orientado ao componente. Alm dessa
categorizao, o aspecto pode ainda ser um aspecto de entrada ou de sada. Os de entrada
realizam aes antes da execuo de um determinado mtodo, enquanto que o de sada aps a
execuo do mtodo. Alm dessa classificao dos aspectos, os componentes tambm foram
classificados nos tipos mais recorrentes em ambientes virtuais de colaborao: Usurio,
Documento e Sala.

Figura 2.10 Aspecto de Controle de Acesso
Para realizar uma instanciao com componentes e aspectos especficos de uma
aplicao, o usurio deve fornecer informaes sobre os tipos dos aspectos especficos, sobre
o tipo dos componentes especficos e tambm sobre o mecanismo de composio entre eles.
Esse ltimo tipo de informao controla quais tipos de aspectos devem interceptar as
mensagens que so enviadas ou recebidas por um certo componente. Todas essas informaes
so armazenadas em uma camada intermediria que mantm registrados tanto os componentes
quanto os aspectos que afetam o comportamento desses componentes. O processo de registro
dos componentes, aspectos e as informaes de composio apoiado por uma linguagem
especial.
public abstract aspect Precheck
{
abstract pointcut pc(..); //arguments omitted

abstract protected Boolean constraint(HttpServletRequest request);
abstract protected String getErrorMessage();
private ActionForward forwardToErrorPage(..) {
request.setAttribute ("message", getErrorMessage());
return mapping.findForward("failure");
}

ActionForward around(..):pc(..)//advice
{
if (constraint(request))
return proceed(mapping,form,request,response);
else
//login redirection
return forwardToErrorPage(request,mapping);
}
}
}


28
Hanenberg et al. (2004) desenvolveram um framework de aplicao orientado a
aspectos de estratgias de caminhamento (traversal strategies). A linguagem orientada a
aspectos utilizada no desenvolvimento do framework foi AspectS. Cada um dos requisitos do
framework (algoritmos de caminhamento, polticas de comportamento, tratamento de ns
adjacentes e poltica de ciclos) foi modelado separadamente em uma hierarquia de classes. A
classe principal chamada Traversal e possui mtodos-gancho (hook methods) que
permitem que o desenvolvedor da aplicao escolha as variabilidades (requisitos) desejadas.
Segundo os autores, a inadequabilidade do mecanismo de composio OO fica
evidente quando essas hierarquias precisam ser combinadas para o fornecimento dos ganchos.
Em conseqncia da independncia dos requisitos, utilizar herana para realizar o
acoplamento causa um aumento de classes com cdigos redundantes.
Eles citam que do ponto de vista do desenvolvimento de frameworks, o que
interessante da orientao a aspectos que o sistema-base naturalmente j possui um conjunto
de ganchos que so os pontos de juno e que podem ser adaptados por aspectos, e
conseqntemente pelo desenvolvedor da aplicao. Eles tambm comentam que esses
ganchos so implicitamente contidos e que no h necessidade de projet-los com
mecanismos adicionais. Os autores consideram a existncia de ganchos explcitos,
representados por estruturas de projeto complexas, como uma desvantagem dos frameworks
orientados a objetos. Contudo, isso no implica que frameworks no necessitem de ganchos
explcitos.
2.4.4 Modelagem de Aspectos
A abordagem Tema um mtodo de desenvolvimento de software orientado a aspectos cujo
objetivo principal trabalhar com interesses desde a fase de anlise at a fase de composio.
Os interesses so modelados como temas, os quais podem ser do tipo base ou transversal.
Os temas-base agrupam as principais funcionalidades do domnio do problema, enquanto que
os transversais encapsulam interesses que afetam os temas-base. Vrios artefatos de projeto
podem existir dentro de um tema, como, por exemplo: diagramas de classe, de seqncia, de
colaborao e de estado. A representao grfica de um tema um pacote (package) da UML.
Os temas podem se relacionar de duas formas: compartilhando conceitos ou
entrecortando-se. O primeiro caso se d quando o mesmo elemento de projeto aparece em
mais de um tema. Neste caso os temas devem ser compostos por relacionamentos de
intercalao (merge) ou sobreposio (override), por exemplo, se uma mesma classe aClass
aparece em mais de um tema, porm com atributos e mtodos diferentes em cada um deles, a
composio desses temas resultar em um tema que possui apenas uma classe aClass com
29
todos os atributos e mtodos oriundos dos temas que esto sendo compostos. Se um mesmo
atributo/mtodo existir em ambas as classes de ambos os temas, apenas um ser colocado no
tema resultante.
Quando um tema encapsula um interesse transversal, sua composio com outros
temas se d por meio de um relacionamento de ligao (bind). Esse tipo de relacionamento
indica que o comportamento do tema transversal disparado quando algum evento ocorre no
tema-base, como uma chamada de mtodo. Dessa forma, o comportamento do tema-base
afetado pelo comportamento do tema transversal.
A fase de projeto da abordagem Tema, chamada de Theme/UML, utiliza uma extenso
dos gabaritos da UML para projetar os interesses transversais. Assim, pode-se projetar o
comportamento transversal independentemente da existncia de um cdigo-base, isto , sem
considerar os pontos reais do cdigo-base que sero afetados. Isso torna os gabaritos da
abordagem Tema adequados para o projeto de aspectos abstratos, e conseqentemente, de
frameworks orientados a aspectos (Camargo e Masiero, 2005b). Alm disso, como diagramas
de seqncia so usados dentro dos temas, tambm possvel modelar a dinmica de como o
interesse transversal afeta o interesse-base.
Na Figura 2.11 mostrado o Tema transversal Log. O objetivo registrar informaes
de contexto de execuo de operaes antes e aps a execuo dessas operaes. Assim, este
interesse projetado sem conscincia do ponto de juno da aplicao que ser afetado, o que
possvel por meio da utilizao de gabaritos. Na caixa tracejada localizada no canto superior
direito do pacote mostrada a classe gabarito LoggedClass e a operao gabarito
loggedOp(), que funcionam como uma lista de parmetros. Esses gabaritos so
representaes abstratas de classes e operaes do cdigo-base que, depois do processo de
composio, sero substitudas por classes e operaes reais.
Apenas durante a etapa de composio que uma ou mais operaes reais de algum
cdigo-base sero associadas com a operao gabarito. O resultado que o comportamento da
operao gabarito ir envolver o comportamento da operao real, como mostrado pelo
diagrama de seqncia dentro do tema. Para representar o comportamento original da
operao que ser substituda, acrescenta-se o prefixo _do_ no nome da operao gabarito,
como pode ser visto na classe gabarito LoggedClass. Assim, pode-se compreender qual ser
o comportamento do sistema depois que esse tema estiver composto com um cdigo-base.
Neste exemplo, quando um mtodo do cdigo-base for executado, representado pelo
loggedOp(), o mtodo write() chamado. Em seguida, executa-se o comportamento

30
original do mtodo entrecortado representado pelo do_loggedOp() e novamente o
mtodo write() invocado.

Figura 2.11 Tema Transversal de Registro de Execuo
Observe-se tambm a existncia de um atributo chamado attribute1 e de uma
operao chamada operation1() na classe gabarito. Aps a etapa de composio, esse
atributo e esse mtodo sero adicionados na classe real que fizer correspondncia com a
classe gabarito. Outro ponto que merece destaque que dentro de um tema transversal pode
existir um nmero arbitrrio de classes. Por exemplo, suponha que a classe aClass
utilizada pela classe LogFile para alguma computao especfica.
O relacionamento de ligao um super-conjunto do relacionamento de
compartilhamento de conceitos. Isso significa que durante uma composio do tipo ligao,
os temas que participam da composio e que possuem os mesmos conceitos
(classes/atributos/mtodos) sero combinados em elementos nicos, como ocorre no
relacionamento de intercalao, por exemplo.
Como descrito no algoritmo de mapeamento para AspectJ proposto por Clarke (Clarke
e Baniassad, 2005), cada tema deve ser implementado como um aspecto abstrato e as
operaes gabarito tornam-se conjuntos de juno abstratos (abstract pointcuts) dentro do
aspecto. Assim, de posse do projeto apresentado na Figura 2.11, por exemplo, o engenheiro
de aplicao sabe da existncia de um aspecto abstrato chamado Log e que ele possui um
conjunto de juno abstrato chamado loggedOp() que deve ser concretizado com pontos
de juno da aplicao especfica. Alm disso, o engenheiro de aplicao tambm consegue
saber qual ser o comportamento do sistema aps a composio analisando o diagrama de
seqncia.
<<theme>>
Log
<LoggedClass.loggedOp()>
: LoggedClass : LogFile
loggedOp( )
write( )
_do_loggedOp( )
write( )
LoggedClass
attribute1
loggedOp()
_do_loggedOp()
operation1()
LogFile
write()
aClass
attribute1
attribute2
operation1()
operation2()
31
O algoritmo de mapeamento apresentado por Clarke e Baniassad (2005) possui certas
limitaes para modelar sistemas implementados em AspectJ. Como a sugesto que cada
tema seja mapeado para um aspecto, no possvel representar hierarquia de aspectos, um
recurso bastante til quando se trabalha com AspectJ. Entretanto, o mapeamento ditado pelo
algoritmo tambm fora detalhes importantes de projeto, por exemplo, como o
comportamento transversal modelado como classes dentro de cada tema, a implementao
tambm deve ser feita dessa forma, retirando o cdigo transversal dos adendos e colocando-os
em classes. Fazendo com que o adendo possua apenas chamadas para classes que encapsulam
os comportamentos transversais. Assim, os aspectos permanecem apenas com o cdigo que
liga o comportamento transversal ao cdigo-base.
Na Figura 2.12 mostrada a composio do tema transversal Log com um tema-base
chamado Base. A composio representada graficamente pela linha tracejada bidirecional
que liga os dois temas. Esse relacionamento de bind especifica operaes do tema-base que
sero associados operao gabarito, e conseqentemente, que sero afetadas pelo
comportamento transversal. Neste caso, o tema-base possui uma classe chamada
Expression com trs mtodos que devem ter sua execuo registrada, o check(), o
asString() e o evaluate(), como pode ser visto na descrio textual anexada linha
tracejada. A etiqueta (tag) ThemeName no relacionamento de ligao especifica o nome do
tema resultante.

Figura 2.12 Composio entre os Tema Log e Base
Aps a identificao e representao dessas operaes no relacionamento de bind,
pode-se criar um aspecto concreto estendendo o aspecto Log e implementar o conjunto de
<<theme>>
Log
<LoggedClass.loggedOp()>
ThemeName (System)
bind[<Expression.{ check(..),
asString(..),
evaluate(..)}>]
<<theme>>
Base
LoggedClass
attri bute1
loggedOp()
do_LoggedOp()
operati on1()
LogFile
write()
aClass
attri bute1
attri bute2
operati on1()
operati on2()
aClass
att ri bute3
operat ion3()
Expressi on
check()
asString()
evaluate()

32
juno loggedOp() com a execuo dos trs mtodos passados como parmetro para a
operao gabarito. A operao gabarito tambm pode ser associada a um conjunto de
operaes, e no apenas a uma nica operao.
Na Figura 2.13 mostrado o tema System resultante da composio. Observe-se que
a classe Expression possui agora todos os atributos e mtodos que ela possua no tema
Base e mais aqueles que havia na classe gabarito LoggedClass. Alm disso, tambm
observe-se que as operaes originais foram renomeadas com o prefixo do_ para diferenciar
entre o comportamento original (sem o prefixo) e o transversal que encapsula o original. Um
exemplo de compartilhamento de conceitos ocorreu com a classe aClass. Como essa classe
era a mesma em ambos os temas, ela foi combinada em apenas uma com todos os atributos e
mtodos oriundos dos dois temas que participaram da composio. Tambm observe-se que
foi gerado um diagrama de seqncia para cada operao afetada pelo comportamento
transversal.

Figura 2.13 Tema Composto
Este modelo resultante auxilia a entender o comportamento geral do sistema. O
diagrama de seqncia da Figura 2.13 mostra o comportamento do mtodo check(), que
agora afetado pelo comportamento transversal de registro de operaes. Um ponto
importante da abordagem Tema, especificamente da fase de composio, que possvel
representar o comportamento transversal de forma genrica, em seguida seu acoplamento com
um cdigo-base (mostrando os pontos de juno que sero afetados), e em seguida o
comportamento do sistema aps a composio. Em razo disso, os gabaritos da abordagem
<<theme>>
System
: Expression : LogFile
check( )
do_check( )
write( )
write( )
LogFile
write()
Expressi on
check()
asString()
evaluate()
do_check()
do_asString()
do_evaluate()
operation1()
aClass
attribute1
attribute2
attribute3
operation1()
operation2()
operation3()
33
Tema so usados nesta tese para modelar os frameworks que foram desenvolvidos (Camargo
e Masiero 2005b).
Outro trabalho que pode ser utilizado para a modelagem de frameworks orientados a
aspectos o de Rausch et al. (2003). Esses autores propuseram uma extenso da UML que
modela separadamente o framework, a aplicao e as regras de composio entre eles. O
enfoque principal a modelagem durante o processo de acoplamento. Tem-se inicialmente
um modelo de anlise que mostra separadamente o framework e um outro modelo que mostra
a aplicao. No segundo modelo, j de projeto, os pontos de composio (chamado pelos
autores de hot spots) so modelados como aspectos e pontos de juno em um diagrama de
classes. O objetivo deixar claro para o desenvolvedor de aplicaes os pontos de
acoplamento. A parte dinmica do modelo de classes representada por meio de um diagrama
de seqncias. Prosseguindo na etapa de projeto, modela-se a composio do framework com
a aplicao. As regras de composio entre os dois modelos so feitas por meio de OCL
(Object Constraint Language).
Embora o perfil UML-F (Fontoura et al., 2002) tenha sido criado especificamente para
frameworks orientados a objetos, muitas de suas etiquetas e esteretipos podem ser utilizados
na modelagem de frameworks orientados a aspectos. Isso possvel porque esse tipo de
framework tambm faz uso da orientao a objetos, possuindo mtodos-gancho e mtodos-
gabarito, por exemplo.
As duas abordagens mostradas anteriormente Tema e UML-F so voltadas para
diferentes nveis de abstrao. Os gabaritos da abordagem Tema so teis para representar
aspectos e classes, j os esteretipos da UML-F so teis para representar particularidades de
nvel mais baixo. Atualmente, pesquisadores comearam a perceber a necessidade de uma
notao para representar aspectos em nvel de arquitetura. Fornecendo uma viso em um nvel
mais alto de abstrao que represente claramente os componentes transversais (ou aspectuais)
que afetam a arquitetura do sistema.
Em um nvel de abstrao ainda mais alto, Krechetov et al. (2006) apresentam uma
abordagem de modelagem orientada a aspectos para o projeto da arquitetura de um software.
A abordagem proposta foi criada pela unio de detalhes notacionais encontrados em quatro
outras abordagens de notao para arquitetura de software. O objetivo fornecer uma viso de
alto nvel da arquitetura de um software em termos dos mdulos-base e aspectuais que o
compem. A parte superior da Figura 2.14 mostra uma viso geral da arquitetura de um
sistema de CVS (Control Version System). Os componentes da arquitetura so representados
por classes sem os compartimentos de atributos e operaes. Os componentes aspectuais

34
utilizam o esteretipo <<aspectual component>> enquanto que os componentes-base utilizam
o esteretipo <<component>>. O relacionamento entre os componentes uma dependncia
convencional da UML, com a diferena de que, no caso dos componentes aspectuais, utiliza-
se o esteretipo <<crosscuts>> para indicar que o componente aspectual entrecorta o
comportamento de um outro componente. Nesse diagrama no h distino entre entrecorte
esttico com declaraes intertipo ou dinmico com conjuntos de juno e adendos. O
objetivo apenas conseguir identificar os mdulos-base que so afetados por mdulos-
aspectuais.

Figura 2.14 Modelagem de Arquitetura Orientada a Aspectos
A parte inferior da Figura 2.14 diminui o nvel de abstrao e mostra mais detalhes do
relacionamento de entrecorte que o componente aspectual Access Control mantm com
CVS Server, destacados na parte superior desta figura. Neste nvel de abstrao as
interfaces de entrecorte dos componentes podem ser exibidas, fornecendo detalhes adicionais
sobre o relacionamento. Por exemplo, o componente aspectual AccessControl possui duas
interfaces de entrecorte, sendo que uma delas afeta outra interface do componente-base e a
ElementListing
Access Control
<<aspectual component>>
TreeView
CVS Server
<<component>>
ObjectAccess
Element Listi ng
showElement()
<<crosscutting interface>>
<<crosscuts>>
Access Cont rol
<<aspect ual component >>
Logging
CVS Client
CVS Server
<<component>>
Persistence
Synchronizat ion
Group Work Logic
<<component>>
<<crosscuts>> <<crosscuts>>
<<crosscuts>>
<<crosscuts>>
35
outra afeta a estrutura interna desse componente. Neste nvel de abstrao tambm possvel
distinguir se o componente aspectual afeta estaticamente ou dinamicamente outro
componente. O entrecorte esttico representado por um relacionamento de associao com
esteretipo <<crosscuts>> enquanto que no entrecorte dinmico esse esteretipo omitido.
Quando for necessrio especificar o conjunto de juno de uma interface de entrecorte,
pode-se utilizar uma classe com esteretipo <<crosscutting interface>> que descreve, em seu
compartimento de mtodos, conjuntos de juno do componente aspectual. Assim, a interface
de entrecorte ElementListing define um conjunto de juno chamado showElement(),
que pode ser visto no compartimento dos mtodos. Essa representao mostra que esse
conjunto de juno afeta dinamicamente os mtodos que estiverem na interface TreeView.
Por outro lado, a interface de entrecorte ObjectAccess afeta estaticamente a estrutura
interna do componente-base (Krechetov et al., 2006).
2.4.S 1ecnicas de Implementao de Aspectos Genericos
Hanenberg e Schmidmeier (2003a; 2003b) propuseram um conjunto de oito idiomas para a
linguagem AspectJ que podem ser utilizados para a implementao de aspectos genricos, e
conseqentemente, de frameworks orientados a aspectos. Segundo Hanenberg et al. (2004), as
tcnicas de composio da POA so mais adequadas para o projeto de ganchos em
frameworks do que as tcnicas de composio da orientao a objetos. Na orientao a
objetos, as tcnicas de composio tradicionais, como herana e composio de objetos,
possuem granularidade grossa, no nvel de classes e objetos, diferentemente da orientao a
aspectos em que a composio pode ser feita diretamente em mtodos. Essa granularidade
grossa faz com que a estrutura do framework fique prejudicada em relao evoluo e
manutenibilidade, bem como ao processo de instanciao. Os oito idiomas, seus papis, a
descrio dos papis e o objetivo podem ser vistos na Tabela 2.2.
O idioma Container Introduction permite encapsular propriedades extrnsecas
15
em
um recipiente, as quais sero introduzidas em um componente
16
em tempo de composio.
Esse idioma possui trs papis: A interface Container, o aspecto ContainerLoader e o
aspecto ContainerConnector. O aspecto ContainerLoader responsvel por definir
uma propriedade extrnseca e adicion-la interface Container. O aspecto
ContainerConnector deve fazer com que o componente implemente a interface

15
Uma propriedade extrnseca um atributo ou mtodo que no diz respeito funcionalidade da classe.
16
Um componente uma unidade modular, possivelmente uma classe, que pertence parte funcional de uma
aplicao.

36
Container. O principal benefcio desse idioma a transparente introduo de propriedades
extrnsecas sem a necessidade de modificar o aspecto ContainerConnector.
Tabela 2.2 Idiomas de Hanenberg e Unland
Idioma Papis Objetivo
Container
Connector
Container
Introduction
Container Loader
Fazer com que propriedades extrnsecas sejam inseridas nas classes de aplicao em
tempo de composio.
Marker Interface
Aspect Specification
Marker
Interface
Marker Sticker
A existncia de um tipo base para todos os objetos da aplicao para que o conjunto
de juno apenas referencie esse tipo base.
Composit Pointcut Composit
Pointcut Component Pointcut
Definir um conjunto de juno de forma mais clara quebrando-o em conjuntos de
juno menores.
Abstract
Pointcut
Pointcut hook

Definir um conjunto de juno abstrato que deve ser concretizado pelo aspecto
concreto.
Primitive Operation Template
Advice
template advice
Fornecer diferentes comportamentos para um adendo por meio das operaes
primitivas.
Pointcut method Pointcut
Method
Candidato
(candidate)
O objetivo a existncia de um adendo condicional, em que sua execuo dependa do
retorno do mtodo conjunto de juno
Abstract Chain
Chain Element
Chain
Advice
Anchor pointcut
Agrupar em um nico aspecto vrios pontos de juno que so compartilhados por
vrios aspectos. Dessa forma os elementos da cadeia apenas definem os adendos e
no os conjuntos de juno
Known Creator
Concrete Creator
Creator pointcut
Factory
Advice
Abstract Product
O objetivo transferir a responsabilidade de criao de objetos das classes de
aplicao para os aspectos.

Outro idioma Marker Interface, que especifica propriedades de interceptao
(conjuntos de juno e adendos) dependentes de uma interface que posteriormente
relacionada a uma aplicao. Esse idioma possui trs papis: a interface MarkerInterface,
o aspecto AspectSpecification e o aspecto MarkerSticker. O aspecto
AspectSpecification possui conjuntos de juno e adendos que apenas referenciam a
interface MarkerInterface. O aspecto MarkerSticker faz com que um determinado
componente implemente essa interface. Dessa forma, esse idioma faz com que os
componentes corretos sejam afetados sem que o aspecto AspectSpecification defina
explicitamente seus nomes e tipos. Isso torna esse aspecto reusvel, j que no possui
dependncia de informaes especficas da aplicao. Esse idioma freqentemente usado
em conjunto com o idioma ContainerIntroduction, em que a interface MarkerInterface
corresponde interface Container, e o aspecto AspectSpecification corresponde ao
aspecto ContainerLoader.
O idioma Composite Pointcut decompe um conjunto de juno em outros conjuntos
de juno componentes, que sejam logicamente independentes. Esses conjuntos de juno
componentes podem ser modificados sem afetar o conjunto de juno composto e podem ser
utilizados em outros aspectos. Os autores comentam que a existncia de um conjunto de
juno com uma definio muito complexa dificulta sua redefinio em classes concretas.
Isso acontece porque a linguagem AspectJ no permite a redefinio de partes de um conjunto
37
de juno. A existncia de conjuntos de juno menores facilita a redefinio de um pequena
parte do conjunto de juno, sem precisar redefini-lo completamente. Geralmente esse idioma
trabalha em conjunto com o idioma Abstract Pointcut em que um dos conjuntos de juno
componentes so abstratos. Da mesma forma, o idioma Marker Interface pode fazer uso de
conjuntos de juno componentes quando a definio do conjunto de juno estiver
complexa.O idioma Template Advice permite especificar adendos com variabilidades. Isso
possvel definindo operaes primitivas que so chamadas a partir de um adendo gabarito que
agrupa o comportamento comum. As operaes primitivas podem ser redefinidas ou
sobrepostas nos aspectos concretos para fornecer detalhes especficos da aplicao. Uma
vantagem desse idioma que o desenvolvedor precisa de pouco conhecimento do conjunto de
juno ou das propriedades internas do adendo. Esse idioma geralmente trabalha junto com o
Abstract Pointcut em que o aspecto ConcreteAspect especifica o conjunto de juno
gancho.
Os autores comentam que o idioma Template Advice em conjunto com o Template
Method e o Composite Pointcut formam a base fundamental para a construo de frameworks
orientados a aspectos em AspectJ.
Outro trabalho que pode ser utilizado como base para a implementao de frameworks
orientados a aspectos apresentdo por Wrampler (2006). Esse autor discute a dificuldade de
se criar aspectos genricos e reusveis em AspectJ. O autor discorre sobre o assunto no
contexto de uma ferramenta chamada Contract4J, que uma ferramenta para
desenvolvimento de programas Java e AspectJ que apia a utilizao de projetos por contratos
(Design By Contract). A ferramenta gera aspectos automaticamente para realizao dos testes
do projeto por contrato. O objetivo do autor gerar aspectos genricos e reusveis em
AspectJ.
Wrampler (2006) comenta que a natureza dos aspectos dificulta sua implementao de
forma genrica. Geralmente os interesses transversais encapsulados pelos aspectos precisam
de alguma cooperao do cdigo-base para funcionar adequadamente. Implementar esses
aspectos de forma totalmente genrica algo difcil. Uma das causas disso que os conjuntos
de juno da linguagem AspectJ, por exemplo, so escritos considerando detalhes do cdigo-
base, e no abstraes de nvel mais alto, como deveria ser. Segundo Wrampler, a idia de
que o cdigo-base deve ser inconsciente dos aspectos inadequada. Ele cita alguns trabalhos
recentes em que o cdigo-base possui conhecimento dos pontos que podem ser afetados por
aspectos (Kiczales e Mezini, 2005; Griswold, et al., 2006).

38
Wrampler comenta que uma forma de tornar os aspectos mais genricos e reusveis
a utilizao de conjuntos de juno baseados em anotaes (annotations), que podem ser
usadas com o Java5 e com o AspectJ5. As anotaes marcam partes do cdigo-base
relacionadas semanticamente e conjuntos de juno podem ser projetados para entrecortarem
essas partes, sem fazer com que eles fiquem presos a convenes de nomenclatura e/ou
detalhes de implementao.
O autor discute trs diferentes implementaes para a gerao dos aspectos e conclui
que a mais genrica e reusvel a que utiliza anotaes (Wrampler, 2006). Na Figura 2.15 so
mostrados dois aspectos gerados por diferentes verses da ferramenta Contract4J. O primeiro
aspecto tem como objetivo entrecortar execues do mtodo withDraw() e realizar o teste
de pr-condio, verificando se o valor passado por parmetro positivo e se o saldo da conta
ficar positivo aps a retirada. Esse aspecto dificilmente pode ser reusado porque seu
conjunto de juno implementado considerando detalhes do cdigo-base que ser
entrecortado, por exemplo, a classe BankAccount.

Figura 2.15 Exemplos de Conjunto de Juno
O segundo aspecto da Figura 2.15 mais genrico e possui grandes chances de reso.
Seu objetivo tambm realizar testes de pr-condies. Nesta segunda alternativa de
implementao o conjunto de juno entrecorta a execuo de qualquer mtodo que pertena
interface ContractMaker. Essa interface criada por um outro aspecto especificamente
para marcar os objetos que sero submetidos aos testes de contrato, como feito no idioma
MarkerInterface (Hanenberg e Schmidmeier, 2003a). Alm disso, os mtodos s so
entrecortados se no forem estticos e se possurem a anotao @Pre, indicando que possuem
public aspect BankAccount_pre_withdraw {

before (BankAccount ba, float amount) :
execution (float BankAccount.withDraw(float)
&& this(ba)
&& args (amount)
{

if (amount >= 0 && ba.getBalance() amount >= 0) {
handleFailure(...);
}
}

}
pointcut preMethod (Pre pre, ContractMaker obj):

if (isPreEnabled()) && !within_c4J() &&
execution (@Pre !static * ContractMaker+.*(..)) &&
@annotation(pre) && this(obj);
39
pr-condio. Somado a isso, tambm s h entrecorte se o mtodo isPreEnabled()
retornar verdadeiro e se a execuo do mtodo estiver fora do escopo de execuo da prpria
ferramenta, o que representado pelo conjunto de juno within_c4j(), o qual no
mostrado na figura.
A estratgia de implementao dos autores interessante, porm no exclui a
necessidade de um aspecto informar quais classes devem implementar a interface
ContractMaker. Essa uma estratgia tambm utilizada no FT de persistncia
desenvolvido no contexto desta tese.
2.4.6 Linhas de Produtos e a Programao Orientada a Aspectos
Como comentado anteriormente, frameworks podem ser utilizados como ferramentas para a
implementao de linhas de produtos e uma estratgia que pode ser utilizada a diviso da
arquitetura do framework em caractersticas. Entretanto, a presena de interesses transversais
tambm tem influncia negativa nessa linha de pesquisa. H caractersticas que possuem
comportamento transversal e que no so adequadamente modularizadas com as tcnicas
existentes. Assim, Mezini e Ostermann (2004) e Apel et al. (2006) propuseram novas
abordagens com vistas a solucionar o problema. A abordagem de Mezini e Ostermann (2004)
contempla uma linguagem chamada CAESAR
17
(Mezini e Osterman , 2003 apud (Mezini e
Ostermann, 2004)). Nessa linguagem, as caractersticas transversais podem ser definidas em
mdulos coesos e incorporadas dinamicamente no cdigo-base por meio de conjuntos de
juno e adendos. Alm disso, tambm possvel generalizar as caractersticas para que elas
no fiquem dependentes da estrutura do programa base e possam ser reusadas em outros
contextos.
A abordagem proposta por Apel et al. (2006) chamada de Aspectual Mixin Layers e
o diferencial que aspectos podem ser refinados com o objetivo de aumentar ou diminuir o
escopo de atuao de um conjunto de juno. Alm disso, tambm possvel delimitar a
quantificao dos aspectos, fazendo com que os conjuntos de juno no afetem
caractersticas inseridas aps a incluso do aspecto.
2.S PROCLSSO DL DLSLNVOLVIMLN1O ORILN1ADO A
ASPLC1OS
Depois do surgimento da POA, vrios pesquisadores tm investigado a influncia desse novo
paradigma em fases especficas do processo de desenvolvimento. Alguns se concentram na

17
MEZINI, M., OSTERMANN, K. Conquering aspects with Caesar. In Proceedings of Conference on Aspect-
Oriented Software Development (AOSD03), pages 90-99. ACM, 2003.

40
fase de anlise e engenharia de requisitos (Grundy, 1999; Clarke e Baniassad, 2005; Rashid et
al., 2002; Baniassad et al., 2006), outros na fase de projeto (Berg et al., 2006; Clarke e
Baniassad, 2005), (Aspect-Oriented Component Engineering) (Grundy, 2000; Katara e Katz,
2003; Suzuki e Yamamoto, 1999; Pawlak et al., 2002; Stein et al., 2002; Zakaria et al., 2002;
Aldawud et al., 2003), outros na fase de implementao (Soares, 2004) e ainda h alguns
poucos que discorrem sobre todo o ciclo de vida (Clarke e Baniassad, 2005; Jacobson e Ng,
2004).
A pesquisa de Grundy (1999) consiste em um mtodo de engenharia de requisitos
orientado a aspectos para desenvolvimento de software baseado em componentes. Ele
desenvolveu uma categorizao de diversos aspectos de um sistema que um componente
prov para os usurios finais ou para outros componentes.
Na fase de anlise da abordagem Tema (Clarke e Baniassad, 2005), os temas so
identificados a partir dos requisitos e, para isso, estabelecida uma relao de cada requisito
(ou conjunto de requisitos) a um tema que o encapsula. Clarke e Baniassad tambm
estabelecem critrios para identificar temas que encapsulam interesses transversais e so
candidatos a serem implementados como aspectos. Os temas que encapsulam interesses
transversais so chamados de temas transversais e em geral so relacionados a mais de um
requisito, enquanto que os outros temas, denominados de temas-base, geralmente so
relacionados a um nico requisito.
Arajo e Moreira (2003) propuseram uma abordagem dirigida a casos de uso, cujo
objetivo identificar casos de uso aspectuais, que podem ser tanto funcionais quanto no-
funcionais. Para realizar essa identificao, parte-se de um documento de requisitos em que
um modelo inicial de casos de uso elaborado. Em seguida os casos de uso so analisados
com o objetivo de fatorar funcionalidades. Isso representado por relacionamentos que
utilizam os esteretipos <<extend>>, <<includes>> e <<constrain>>. A partir disso, os
requisitos no-funcionais do sistema so identificados e modelados como casos de uso com
esterotipo <<NFR>>, que so integrados com os casos de uso funcionais j elaborados. O
relacionamento que os casos de uso no-funcionais mantm com os funcionais deve ser
representado pelo esteretipo <<constrain>>. O ltimo passo consiste em identificar os casos
de uso candidatos a aspectos, que so aqueles que restringem mais de um caso de uso, ou que
so includos ou estendidos por mais de um caso de uso.
O modelo AORE, (Aspect-Oriented Requirements Engineering) proposto por Rashid
et al. (2002), relaciona interesses a requisitos com o objetivo de verificar quais interesses
entrecortam os requisitos, qualificando-os como candidatos a aspectos. O modelo permite
41
separar a especificao dos requisitos aspectuais, requisitos normais e regras de composio
em mdulos que seguem gabaritos bem definidos. As regras de composio empregam
operadores e aes para especificar como um requisito aspectual influencia ou restringe o
comportamento de um conjunto de requisitos normais.
Com relao fase de projeto, tambm h um nmero significativo de trabalhos,
sendo que muitos deles se concentram em estender tcnicas de projeto orientadas a objetos e
tambm a UML com detalhes que permitem a modularizao de interesses transversais. As
principais abordagens so Tema/UML (Clarke e Baniassad, 2005), AOCE (Aspect-Oriented
Component Engineering) (Grundy, 2000), Viso Arquitetural de Aspectos (Architectural
View of Aspects) (Katara e Katz, 2003), aSide (Chavez, 2004; Berg et al., 2006) e a
abordagem proposta por Suzuki e Yamamoto (Suzuki e Yamamoto, 1999). Tambm h outros
cujo enfoque mais restrito proposta de uma perfil UML especfico para AspectJ para a fase
de projeto (Pawlak et al., 2002; Stein et al., 2002; Zakaria et al., 2002; Aldawud et al., 2003).
A abordagem AOCE refina os requisitos identificados na abordagem AORE em
aspectos de nvel de projeto (Grundy, 2000). Essa abordagem baseada na idia de que cada
componente em um sistema baseado em componentes usa/prov servios de/para outros
componentes. Um conjunto de extenses da UML empregado para tornar os detalhes
aspectuais explcitos.
Na abordagem Viso Arquitetural de Aspectos (Katara e Katz, 2003), os aspectos so
representados como pacotes estereotipados contendo artefatos da UML que pertencem a um
determinado interesse. Os elementos dentro de cada diagrama podem ter relaes, como uses
ou defines, e podem se mapeados para outros elementos em aspectos diferentes. A noo de
diagrama de interesse (concern diagram) introduzida e permite visualizar sobreposies de
interesses.
Tema/UML (Clarke e Baniassad, 2005) uma combinao do modelo de projeto
orientado a assunto e dos gabaritos da UML. Regras de composio so utilizadas para
compor os projetos. Aps a identificao dos temas-base e transversais, os temas so
projetados separadamente. No projeto de um tema transversal, diagramas de interao so
especificados para mostrar o comportamento-padro do tema quando combinado com algum
tema-base da aplicao. Para isso, so adotados gabaritos em que as operaes entrecortadas
so representadas genericamente nos diagramas e so substitudas pelas operaes dos temas-
base na composio. A abordagem baseada na observao de que padres de
comportamentos transversais existem com respeito a projetos-base que eles entrecortam.
Assim, o comportamento transversal pode ser projetado sem conscincia do cdigo-base.

42
Na abordagem aSide (Chavez, 2004), o modelo de projeto proposto compreende trs
facetas, a estrutural, a dinmica e a de composio. A primeira modela a estrutura dos
aspectos e componentes, e como se relacionam por meio de interceptaes e mecanismos de
composio tradicionais. A faceta dinmica modela as interaes entre as instncias dos
aspectos e dos componentes afetados por esses aspectos, e a faceta de composio visa a
facilitar a compreenso da combinao dos aspectos com os componentes em um nvel mais
alto de abstrao.
Suzuki e Yamamoto propuseram extenses da UML para modelar aspectos e tambm
uma linguagem de descrio baseada em XML chamada UXF/a para fornecer converses de
modelos baseados em aspectos entre ferramentas de desenvolvimento (Suzuki e Yamamoto,
1999). Um aspecto representado como uma classe com atributos, operaes e
relacionamentos. Os atributos so usados pelo conjunto de operaes, as quais so as
definies de composio do aspecto. As assinaturas dessas definies refletem os elementos
afetados pelo aspecto.
Soares (2004) apresenta um mtodo de implementao orientado a aspectos e sua
integrao com o Processo Unificado da Rational (Rational Unified Process - RUP)
(Jacobson et al., 1999). O autor comenta algumas modificaes devem ser feitas tanto na
estrutura dinmica (fases) como na esttica (disciplinas e atividades) do RUP para a utilizao
do mtodo. A principal modificao realizada na parte dinmica a realizao de iteraes
especficas para requisitos no-funcionais. Assim, casos de uso que devem ser implementados
em uma iterao so parcialmente implementados em uma iterao funcional, em que apenas
requisitos funcionais, interfaces com o usurio e gerenciamento de dados no persistentes so
implementados. Depois que essa implementao validada, os requisitos no-funcionais de
persistncia, distribuio e concorrncia so incorporados em trs iteraes no-funcionais.
Jacobson e Ng (2004) propem uma abordagem de desenvolvimento de software
orientado a aspectos com base em casos de uso. A proposta identificar interesses
transversais a partir dos casos de uso de um sistema e implement-los em mdulos separados.
Na abordagem de Jacobson e Ng (2004) os casos de uso que implementam interesses
transversais so identificados principalmente pelos relacionamentos (include ou extend) que
estabelecem com os outros casos de uso. Com base nessa deciso, foram estabelecidos
critrios que orientam os desenvolvedores na deciso de quais tipos de relacionamentos os
casos de uso tm entre si. Cada interesse do sistema descrito por um caso de uso e o sistema
completo obtido pela composio dos casos de uso base e transversais. Na implementao,
cada caso de uso pode ser composto por uma ou mais classes que possuem mtodos e
43
atributos relacionados ao interesse descrito. Jacobson e Ng (2004) propem a codificao de
todos os casos de uso com linguagens orientadas a aspectos e que a composio para produzir
o sistema completo seja feita por meio de declaraes intertipo em entidades vazias
previamente criadas.
2.6 CONCLUSO
Os trabalhos apresentados nas Sees 2.4.1 e 2.4.2 tratam da implementao de interesses
transversais com POA de forma que possam ser reusados durante o desenvolvimento de novas
aplicaes. Apesar de serem similares com relao implementao e objetivos, no h um
consenso sobre o termo utilizado para designar esse tipo de implementao. Enquanto alguns
autores utilizam o termo framework de aspectos (Soares, 2004; Hanenberg, 2000), outros
utilizam framework baseado em aspectos (Rashid e Chitchyan, 2003), outros ainda utilizam
framework orientado a aspectos (Mendona et al., 2005; Constantinides et al., 2000; Shah e
Hill, 2004; Rausch et al., 2003; Pinto et al., 2001a; Pinto et al., 2001b; Pinto et al., 2002) e
tambm pode ser encontrado framework (arcabouo) orientado por aspectos (Couto et al.,
2005).
Essa falta de consenso mais grave em trabalhos que utilizam os mesmos termos
citados acima para designar um outro tipo de framework que utiliza aspectos em sua
arquitetura interna os frameworks de aplicao (Pinto et al., 2001a; Pinto et al., 2001b;
Pinto et al., 2002; Hanenberg et al., 2004). Esse tipo de framework possui objetivos diferentes
e implementado de forma diferente, pois encapsula uma arquitetura genrica de um domnio
de aplicao e o seu reso resulta em uma aplicao inteira daquele domnio.
Um ponto digno de nota com relao aos frameworks apresentados nas Sees 2.4.1
e 2.4.2 a ausncia de uma arquitetura padro que separe as funcionalidades do framework
(por exemplo, suas variabilidades) de seus mecanismos de composio (sua interface de
entrecorte). A existncia de uma arquitetura desse tipo propicia uma melhor evoluo para
esse tipo de software porque permite que variabilidades sejam includas sem afetar outras
partes da implementao.
Entretanto, a existncia de uma arquitetura de refrencia para frameworks orientados
a aspectos no suficiente para proporcionar um reso efetivo. Como comentado na Seo
2.3, frameworks possuem o problema de overfeaturing (Codenie et al., 1997 apud (Batory et
al., 2000))
18
, isto , o reso do framework faz com que todas a sua arquitetura seja
considerada, independentemente se todas as suas variabilidades estejam sendo utilizadas ou

18

44
no. Uma soluo modularizar a arquitetura do framework em caractersicas, assim, o
framework tambm deve ser montado antes que seja reusado apenas com as caractersticas
que sero utilizadas.
A maior parte dos trabalhos encontrados na literatura relacionados com
desenvolvimento de software orientado a aspectos concentra-se em fases ou atividades
especficas do ciclo de vida, como engenharia de requisitos, anlise, projeto, projeto de
arquitetura e implementao. Entretanto, apesar de que pesquisas em fases isoladas do ciclo
de vida sejam preciosas para definir e aprofundar os conceitos, tambm necessrio unir
essas fases para mostrar como os interesses transversais so identificados, reusados e
conduzidos durante todo o processo de desenvolvimento.
Os nicos trabalhos que unem anlise e projeto so a abordagem Tema e a abordagem
de desenvolvimento orientada a casos de uso proposta por Jacobson e Ng (2004), porm,
ambos possuem algumas deficincias. A notao utilizada na fase de anlise da abordagem
Tema empregada em um nvel de abstrao baixo, resultando em um modelo volumoso e
que necessita de apoio automatizado para o entendimento (Clarke e Baniassad, 2005). Outro
detalhe que nenhuma das duas abordagens enquadrada em algum modelo de processo,
como, por exemplo, o RUP e o gil. Por outro lado, Tema fornece alguns critrios
interessantes para a identificao de interesses transversais que no so encontrados na
abordagem de Jacobson e Ng.

Captulo 3
r ave ror /. 1rav. re r. ai .: Def i vi oe .,
Ct a. .i f i caoe. e .r qvi t et vr a
3.J CONSIDLRALS INICIAIS
Como pde ser observado no Captulo 2, so vrios os termos utilizados para designar
frameworks que tratam de um nico interesse e que so implementados com aspectos.
Tambm destacou-se a ausncia de uma arquitetura padro para o desenvolvimento desse tipo
de software. Neste captulo, apresentam-se propostas de definies e classificaes que visam
a suprimir a deficincia identificada (Camargo e Masiero, 2005a). O objetivo facilitar a
comunicao entre desenvolvedores quando se referenciam a esse tipo de software. Neste
captulo tambm apresentada uma arquitetura de referncia para o projeto e implementao
desses frameworks. Essa arquitetura pode fazer uso de um padro que permite fornecer
alternativas de composio para o framework.
Na Seo 3.2 so apresentadas as definies e classificaes sugeridas para os
frameworks desenvolvidos no contexto da POA e na Seo 3.3 discute-se e exemplifica-se a
arquitetura proposta para o desenvolvimento desse tipo de framework.
3.2 IRAMLWORKS ORILN1ADOS A ASPLC1OS: DLIINILS
L CLASSIIICALS
A definio geral para Frameworks Orientados a Aspectos (FOA) leva em considerao dois
pontos de vista: a estrutura e o propsito. Do ponto de vista da estrutura, um FOA um
conjunto formado por unidades bsicas de programao OO (classes), cuja presena no
obrigatria, e unidades bsicas de programao OA (aspectos), formando uma estrutura semi-
completa que necessita ser completada com detalhes de uma aplicao especfica.
Captulo 3 Frameworks Transversais: Definies e Arquitetura

46
Essa definio implica que um FOA pode conter apenas aspectos em sua estrutura, e
embora isso no seja comum, possvel que ocorra em situaes especiais. Por exemplo, o
framework pode conter todo o comportamento do interesse transversal implementado como
mtodos pelo aspecto. Embora essa no seja uma estratgia de projeto que separe
adequadamente os interesses, possvel que ocorra.
Do ponto de vista do propsito, assim como os frameworks orientados a objetos, um
FOA pode ser definido como um sistema semi-completo que pode ser reusado no
desenvolvimento de novas aplicaes, mantendo os interesses transversais separados dos
interesses-base. Essa definio implica que o objetivo do FOA facilitar o desenvolvimento
de uma nova aplicao, reusando projeto e cdigo j testados e aprovados, e manter os
interesses transversais separados dos interesses-base do sistema, elevando assim, os nveis de
qualidade da aplicao.
Alm das definies apresentadas anteriormente, a experincia com o
desenvolvimento de vrios frameworks no contexto da POA mostrou que os FOAs podem ser
classificados em dois tipos: Frameworks Transversais e Frameworks de Aplicao Orientados
a Aspectos. Embora essas duas classificaes tenham sido criadas, o enfoque desta tese nos
Frameworks Transversais.
Um Framework Transversal (Crosscutting Framework) (FT) um FOA que encapsula
comportamento genrico de um nico interesse. Possui mecanismos de composio abstratos
e pode ou no possuir variabilidades funcionais. Esse tipo de framework bastante similar a
um framelet em seu propsito (Pree e Koshimies, 2000), como descrito no Captulo 2,
porm diferente na tcnica de implementao utilizada, no causando espalhamento e
entrelaamento de cdigo de interesses distintos.
Como um interesse pode ser composto por outros sub-interesses, fica a critrio do
projetista implementar os sub-interesses com aspectos. Caso isso seja feito, tambm sua
responsabilidade determinar o nvel de granularidade desses sub-interesses e decidir se devem
ser implementados genericamente, na forma de um FTs, ou de forma especfica, deixando seu
acoplamento restrito ao interesse maior.
Quando esses sub-interesses so variabilidades do interesse maior, sua implementao
com aspectos, seja como FT ou como aspectos normais, factvel porque facilita o
acoplamento e o desacoplamento. Em ambos os casos, quando se trata de uma famlia de FTs
de um domnio especfico, esse sub-interesse pode ser usado como uma caracterstica do
interesse maior.
47
A implementao de caractersticas como FTs faz com que elas se tornem-se mais
genricas, podendo possuir variabilidades e aumentando as possibilidades para serem
reusadas tambm fora de sua linha de produtos. Entretanto, como a maior probabilidade de
reso da caracterstica dentro da linha, deve haver uma camada de implementao
independente que fornea o cdigo de acoplamento dela com a caracterstica-base da linha
que geralmente um FT que implementa um interesse maior. No contexto desta tese, esta
camada de implementao chamada de camada de pr-composio, pois contm o cdigo
de acoplamento com o FT que implementa o interesse maior, eliminando essa tarefa do
engenheiro de software. O prefixo pr utilizado porque a composio definitiva s ocorre
se a caracterstica for considerada no projeto. Outro ponto que merece destaque que as
caractersticas que possuem camada de pr-composio tambm possuem os modelos de
projeto da composio prontos com o FT que implementa o interesse maior.
A definio apresentada deixa claro que, obrigatoriamente, deve haver mecanismos de
composio abstratos, por exemplo, conjuntos de juno abstratos no caso da linguagem
AspectJ. Isso necessrio porque o objetivo que o comportamento do FT funcione
acoplando-o a qualquer cdigo-base. Note-se que um FT no precisa, obrigatoriamente, ter
variabilidades. Geralmente a primeira verso de um FT no possui variabilidades funcionais,
pois elas so identificadas e implementadas conforme o FT reusado em novos contextos.
Uma outra propriedade de um FT que sua utilizao dependente da existncia de
um cdigo-base (aplicao), isto , seu reso no produz uma aplicao. Por isso, seu
processo de reso possui duas etapas distintas: instanciao e composio, e no apenas uma,
como ocorre com os FOO. A instanciao o processo convencional de reso dos FOOs e
consiste em especializar o cdigo que foi especialmente projetado para isso. o processo pelo
qual implementam-se os ganchos do framework, escolhe-se alguma funcionalidade alternativa
ou implementa-se uma nova. Isso feito normalmente sobrepondo-se mtodos que retornam
valores da aplicao especfica.
A etapa de composio por sua vez, consiste em duas atividades: identificao dos
pontos de juno e fornecimento de regras de composio. A primeira atividade consiste em
identificar no cdigo-base o(s) ponto(s) de juno adequado(s) ao acoplamento. A segunda
atividade da etapa de composio consiste em fornecer regras que unem as variabilidades
escolhidas com o cdigo-base, e para isso tarefas orientadas a aspectos devem ser realizadas
como, por exemplo, a concretizao de um mecanismo de composio abstrato ou a utilizao
de declaraes intertipo, no caso da linguagem AspectJ (Gradecki and Lesiecki, 2003). Na
maior parte das vezes, a etapa de composio depende de informaes que so determinadas

48
na etapa de instanciao, o que define uma ordem de realizao: primeiro a instanciao e
depois a composio.
Embora essas duas etapas sejam distintas com relao a seus propsitos, sua separao
fsica pode no existir durante o reso, pois isso depende do projeto do framework e da
linguagem orientada a aspectos utilizada. Visto que algumas abordagens OA tendem a separar
as regras de composio do comportamento transversal (Tarr et al, 2002; JAML, 2004),
infere-se que o projeto de um framework deste tipo deve ser elaborado com o objetivo de
separar as duas etapas tanto quanto possvel. Entretanto, como AspectJ uma abordagem que
mantm as regras de composio no mesmo mdulo do comportamento transversal, um bom
projeto precisa ser elaborado para que essas duas etapas tambm sejam separadas.
Assim como nos framelets, o fluxo de controle principal da aplicao, porm nos
pontos em que o FT atua, o fluxo de controle retido por ele. Na Figura 3.1 mostrada uma
comparao entre o fluxo de controle de uma aplicao que utiliza um framelet e uma
aplicao que utiliza um FT. Os vrtices do grafo representam mtodos e as arestas
representam chamadas explcitas entre esses mtodos. As arestas esto numeradas para
representar a ordem das chamadas. No caso do framelet (grafo do lado esquerdo), quando o
mtodo b() atingido pelo fluxo, invoca-se explicitamente o mtodo c() do framelet,
transferindo para ele o controle. Dentro do mtodo c(), os mtodos abstratos d() e e()
so invocados, os quais foram concretizados no nvel da aplicao pelos mtodos d() e e().
Neste momento, como as chamadas dos mtodos d() e e() ocorrem do framelet para o nvel
da aplicao, o fluxo de controle determinado pelo framelet, o que caracteriza a inverso de
controle. Depois que os mtodos d() e e() terminam sua execuo, o controle retorna para a
aplicao, pois o mtodo b() invoca o mtodo f(), que por sua vez, que invoca o mtodo
g().
No caso do FT (grafo do lado direito), quando o mtodo b() atingido pelo fluxo no
h uma chamada explcita ao mtodo c(), o que ocorre que a execuo do mtodo b()
entrecortada pelo FT, o que est sendo representado pela seta tracejada que parte do mtodo
c() em direo ao mtodo b(). Neste momento, o fluxo de controle transferido para esse
framework. Em seguida o processo o mesmo de um framelet, que consiste em invocar
mtodos abstratos que encontram-se concretizados no nvel da aplicao.
Note-se que a nica diferena de um FT e de um framelet, com relao ao fluxo de
controle, que no caso do framelet, a aplicao necessita chamar explicitamente alguma
operao ou mtodo do framelet, um procedimento igual utilizao de uma biblioteca de
classes. Entretanto, depois que o controle foi transferido para o nvel do framework, o
49
comportamento de ambos igual, consistindo de chamadas a mtodos concretizados no nvel
da aplicao, caracterizando o princpio de Hollywood (Johnson, 1997).

Figura 3.1 Inverso de Controle nos Framelets e nos Frameworks Transversais
No contexto desta tese, os FTs dividem-se ainda em duas outras classificaes:
dependentes de contexto e independentes de contexto. Os FTs independentes de contexto so
aqueles que podem ser acoplados a qualquer cdigo-base, e que no possuem exigncia
quanto aos pontos de juno fornecidos. Geralmente FTs de registro e rastreamento de
operaes se enquadram nessa categoria. J os FTs dependentes de contexto necessitam
capturar algum objeto ou valor do cdigo-base para que possam funcionar adequadamente,
isto , sua interface de entrecorte dinmica deve expor determinados objetos ou valores do
cdigo-base para que o FT possa captur-los. Exemplos de FTs que se enquadram nessa
categoria so Repositrio de Conexes, Memria Auxiliar e Autenticao.
Como o conceito de interface de entrecorte est ligado a conjuntos de juno, um
nico aspecto pode possuir vrias interfaces de entrecorte. Como FTs podem possuir vrios
aspectos, pode ser que tenham vrias interfaces de entrecorte. Uma situao que pode ocorrer
a existncia de interfaces de entrecorte tanto na arquitetura interna do Framework quando
durante o processo de reso. As interfaces de entrecorte disponveis durante o processo de
reso geralmente devem ser implementadas pelo engenheiro de aplicao com pontos de
juno do cdigo-base. Por exemplo, o FT de persistncia, que ser mostrado em detalhes na
Seo 4.3, possui ambas as interfaces. Entretanto, durante o processo de reso a nica
1
2
Aplicao Framelet
3
4
5
a
b
d' d
e
f
g
e'
c
6
1
2
Aplicao FT
3
4
5
a
b
d' d
e
f
g
e'
c
6

50
interface que visvel ao engenheiro de aplicao a esttica, pois ele deve informar quais
so as classes de aplicao em que as operaes do framework devem ser introduzidas. A
interface de entrecorte dinmica atua internamente, na estrutura do FT, e s visvel ao
engenheiro do framework.
O reso proporcionado pelos FTs bastante abrangente, no sentido de que pode ser
utilizado em diferentes domnios. Ele pode ser acoplado a aplicaes existentes ou em
desenvolvimento, a frameworks OO e a outros frameworks transversais. Muitas vezes esses
frameworks so variabilidades de um outro FT, por exemplo, nos FTs desenvolvidos no
contexto desta tese, o FT de polticas de bloqueamento uma variabilidade opcional do FT de
Autenticao.
Alm da classificao apresentada de FTs, tambm foi cunhada uma outra
classificao que envolve frameworks que utilizam aspectos em sua estrutura interna e que
geram uma aplicao em um determinado domnio. Assim, Um Framework de Aplicao
Orientado a Aspectos (FAOA) um FOA que implementa uma arquitetura genrica de um
domnio de aplicao e sua instanciao produz uma aplicao desse domnio. A arquitetura
do FAOA projetada com classes e aspectos de forma integrada dentro da arquitetura do
framework
Os FAOA so bastante parecidos com os frameworks de aplicao OO com relao ao
seu propsito e suas diferenas esto na sua arquitetura, que usa aspectos abstratos e
concretos, bem como classes abstratas e concretas para implementar partes variveis de seu
cdigo e que, portanto, so concretizados quando ocorre a instanciao de uma aplicao.
Nesses frameworks o princpio de inverso de controle continua vlido.
H trs formas possveis de reso quando se trata de FOAs e, muitas vezes, sua
natureza (FT ou FAOA) determina essa forma. As formas possveis so: 1) apenas
instanciao, 2) apenas composio, e 3) instanciao e composio.
A primeira forma ocorre somente com FAOAs porque esses j possuem o cdigo-base
embutido em sua estrutura, no necessitando ser acoplados a nenhum outro cdigo-base.
Alm disso, a maioria de seus interesses transversais j est codificada internamente, assim
como suas regras de composio. A segunda ocorre somente com FTs com uma nica
funcionalidade. Um exemplo um FT de rastreamento (tracing), em que a nica
funcionalidade o armazenamento das informaes em arquivos de texto. Nesse caso, a nica
etapa de reso a composio. Frameworks desse tipo so muito simples e limitados com
relao aos benefcios do reso. A terceira forma de reso um pouco mais complexa porque
utiliza as duas etapas. Um exemplo um FT de conexo em que suas variabilidades
51
funcionais so relacionadas com a escolha do banco de dados e com o driver de conexo.
Reusar esse framework consiste em escolher a variabilidade desejada na etapa de instanciao
e tambm fazer a composio com algum cdigo-base.
Nas duas ltimas formas de reso, a composio pode ocorrer entre dois ou mais FTs e
regras de prioridade de atuao precisam ser definidas. Os FTs so os que ocorrem mais
comumente nessa categoria, entretanto, nada impede a existncia de FAOA cujo processo de
instanciao tambm inclua a etapa de composio.
As formas de reso apresentadas so vlidas para frameworks caixa-branca. Quando o
framework caixa-preta, no importa como foi projetada a arquitetura da parte varivel, pois
todas as variabilidades j foram concretizadas e trata-se apenas de um processo de escolha
que geralmente feito com auxlio automatizado.
3.3 PROPOS1A DL UMA ARQUI1L1URA PARA IRAMLWORKS
1RANSVLRSAIS
Embora vrios artigos tenham sido publicados sobre FTs, nenhum deles prope uma
arquitetura para o desenvolvimento desse tipo de software. A arquitetura proposta
esquematicamente mostrada na Figura 3.2. H duas partes distintas, uma que implementa o
comportamento transversal encapsulado pelo framework e outra que possui o papel de
conector com algum cdigo-base. A parte destacada com a letra (a) possui apenas classes
que implementam a parte fixa (preenchido com a cor preta) e varivel (sem preenchimento)
do comportamento transversal encapsulado pelo framework. Essa parte geralmente
implementada com padres de projeto comumente usados no desenvolvimento de
frameworks, como por exemplo, Estratgia (Strategy), Mtodo Gabarito (Template Method) e
Fbrica de Objetos (Object Factory) (Gamma et al., 1995). A parte destacada com a letra (b)
possui apenas aspectos que implementam a parte fixa e varivel da composio. A parte
varivel desses aspectos implementada por meio de mecanismos de composio abstratos,
como por exemplo, conjuntos de juno abstratos. As setas tracejadas que partem dos
aspectos em direo s classes representam dependncias. Quando os FTs so dependentes de
contexto, essa parte deve ser implementada com o padro Capturador de Dados (Data
Catcher), um padro de projeto proposto no contexto desta tese.
Essa diviso em duas partes consiste em retirar dos aspectos todo o cdigo que diz
respeito ao comportamento funcional do framework e coloc-lo em classes, deixando nos
aspectos apenas o cdigo responsvel por expor um determinado conjunto de pontos de
juno e o cdigo responsvel por invocar mtodos das classes. Essa diviso facilita

52
manutenes tanto na parte do comportamento quanto na parte dos aspectos, pois no h
entrelaamento de interesses entre essas partes. Alm disso, tambm facilita a implementao
de FTs em outras abordagens orientadas a aspectos, como por exemplo JBoss-AOP (JBoss,
2006) e JASCO (Suve et al., 2003), pois essas linguagens tambm trabalham com a idia de
conectores.

Figura 3.2 Arquitetura de Referncia para Frameworks Transversais

Na Figura 3.3 mostrado esquematicamente o processo de reso de um framework
transversal desenvolvido com base na arquitetura proposta. Do lado esquerdo da figura
encontra-se o FT e do lado direito uma aplicao hipottica. Do lado do FT, a letra (c) destaca
uma diviso na parte superior encontram-se as classes do FT e na parte inferior as classes e
aspectos criados pelo engenheiro de aplicao durante o processo de reso.

Figura 3.3 Representao Esquemtica da Instanciao de um Framework Transversal
Na etapa de instanciao (escolha de variabilidades), subclasses so criadas e mtodos
so concretizados com o objetivo de escolher alguma variabilidade do comportamento
disponvel no FT, o que est sendo representado pela letra (d). Na segunda etapa do processo
de reso, que a composio, aspectos especializados so criados com o objetivo de fornecer
regras de composio, isto , pontos de juno da aplicao alvo onde a variabilidade
(c)
(f)
(a)
Aplicaao

(f)
(b)
(d) (e)
l1

53
(comportamento) escolhida na primeira etapa deve atuar, o que est sendo representado pela
letra (e). Assim que as regras de composio forem definidas, os aspectos sabem os pontos da
aplicao que devem ser entrecortados, o que est sendo representado pelas setas marcadas
com as letras (f).
Ainda em relao arquitetura de referncia apresentada na Figura 3.2, sugere-se que
a parte responsvel pela composio com o cdigo-base seja implementada com um padro de
projeto, proposto no contexto desta tese, denominado de Capturador de Dados (Data Catcher)
(Camargo e Masiero, 2005a). Convm ressaltar que esse padro s faz sentido se for utilizado
com FTs dependentes de contexto, isto , aqueles cuja interface de entrecorte necessita
capturar dados do cdigo-base para que possam funcionar.
Para justificar a importncia desse padro, na Figura 3.4 mostrada a implementao
convencional de um aspecto que faz parte de um FT dependente de contexto de Pooling. O
objetivo desse FT interromper a criao de conexes do cdigo-base impedindo que a
aplicao crie uma nova conexo se houver alguma disponvel no repositrio. Se no houver,
o FT devolve o controle para a aplicao, permitindo que ela gere uma nova conexo, porm
captura esse novo objeto Connection e o coloca no repositrio. H um conjunto de juno
abstrato denominado poolConcrete() e um adendo que implementa o comportamento que
ir atuar no ponto de juno fornecido pelo engenheiro de aplicao.

Figura 3.4 Implementao Convencional de um FT de Pooling
Note-se que nesta implementao o cdigo do adendo sempre realiza a captura do
objeto Connection por meio da declarao thisJoinPoint.getTarget(), mas nada
garante que em todo cdigo-base ao qual esse FT for acoplado haver um ponto de juno
cujo objeto alvo da chamada/execuo de um mtodo seja o objeto Connection. Nesse
contexto, uma alternativa fornecer alternativas de composio, dando mais flexibilidade ao
cdigo e permitindo que o responsvel pelo desenvolvimento escolha uma alternativa
public abstract Aspect{

public abstract pointcut poolConcrete();

void around(): poolConcrete(){
{
...

connection = thisJoinPoint.getTarget();

...
}
...
}

54
adequada. Como est implementado, pode no ser possvel reusar o FT em determinados
contextos. Uma alternativa ao uso desse padro modificar o cdigo-base para se adequar ao
FT, mas nada garante que o cdigo-fonte sempre estar disponvel.
Na Tabela 3.1 encontram-se as seis alternativas de composio do padro Capturador de
Dados. A segunda coluna contm o nome da alternativa e a terceira uma descrio que explica
os detalhes das regras de composio que devem ser fornecidas e que aspecto deve ser
estendido, o qual pode ser visto no diagrama apresentado pela Figura 3.5. Por exemplo, a
alternativa WithReturn exige que o aspecto WithReturn seja estendido e que a regra de
composio fornecida pelo engenheiro de aplicao identifique um ponto de juno no
cdigo-base que seja a chamada ou a execuo de um mtodo que retorne o dado requerido
pelo FT.
Tabela 3.1 Alternativas do Padro de Composio
N Alternativa de
Composio
Descrio
1 WithReturn
Esta alternativa consiste em estender o aspecto WithReturn e fornecer um ponto
de juno que seja a chamada ou a execuo de um mtodo cujo retorno o
objeto/valor requerido pelo FT.
2 This
Esta alternativa consiste em estender o aspecto This e fornecer um ponto de
juno cujo objeto this possa ser utilizado para a obteno do valor sujeito ao
clculo por meio do mtodo getGetMethodInChargeOfGettingValue().
Tambm deve ser possvel atribuir o valor modificado a esse mesmo objeto por
meio do mtodo getSetMethodInChargeOfSettingValue(). Esse ponto de
juno pode ser uma chamada ou execuo de um mtodo, ou o acesso a um
atributo.
3 Target
Semelhante alternativa anterior, porm o aspecto a ser estendido Target e o
objeto target do ponto de juno fornecido que ser utilizado para obteno e
atribuio do valor modificado.
4 Args
Semelhante alternativa anterior, porm o aspecto a ser estendido o Args e o
parmetro do ponto de juno fornecido ser determinado pelo ndice fornecido
pelo engenheiro de aplicao por meio da concretizao de um mtodo abstrato.
5 WithTwoParameters
Esta alternativa consiste em estender o aspecto WithTwoParameters e fornecer
um ponto de juno com dois parmetros, em que o primeiro parmetro um
objeto que pode ser utilizado para obter o valor a ser modificado, e o segundo
objeto dever poder receber o valor modificado.
6 OneArgument
Esta alternativa consiste em estender o aspecto OneArgument e fornecer um
ponto de juno que seja a chamada ou a execuo de um mtodo cujo nico
parmetro seja o valor sujeito ao clculo.

A escolha da alternativa que deve ser utilizada depende dos dados que o framework
requer do ponto de juno, isto , de sua interface, e tambm da estrutura do cdigo-base. Na
Tabela 3.2 mostrado um modelo de deciso que auxilia na escolha da melhor alternativa.
Cada linha da tabela consiste em uma pergunta que conduz alternativa de composio
correta da Tabela 3.1. Esse modelo de deciso deve ser utilizado cada vez que uma
variabilidade do framework instanciada durante o processo de reso.
55
Na Figura 3.5 mostrada uma hierarquia de classes que representa os papis do padro.
Apenas ilustrativamente, cada classe da hierarquia do aspecto Aspect representa um aspecto.
Os aspectos abstratos marcados com um asterisco (*) representam as seis alternativas de
composio que podem ser especializadas pelo engenheiro de aplicao. A parte que trata das
variabilidades est representada com a letra (a) e as classes/aspectos que devem ser criadas
durante o processo de reso so representados pelas letras (c) e (d).
Tabela 3.2 Modelo de Deciso
Modelo de Decisao Alternatia de
Composiao
H no cdigo-base um ponto de juno cujo retorno o dado requerido pelo FT? 1
H no cdigo-base um ponto de juno cujo objeto target possui mtodos de leitura e
escrita do dado requerido pelo FT?
2
H no cdigo-base um ponto de juno cujo objeto this possui mtodos de leitura e
escrita do dado requerido pelo FT?
3
H no cdigo-base um ponto de juno para o qual algum de seus argumentos seja um
objeto que tenha mtodos de leitura e escrita do dado requerido pelo FT?
4
H no cdigo-base um ponto de juno cujo objeto target tenha mtodo de leitura do
valor sujeito ao clculo e que o objeto this tenha mtodo de escrita, ou vice-versa?
5
H no cdigo-base um ponto de juno para o qual o seu nico argumento seja o valor
sujeito ao clculo?
6

Figura 3.5 Projeto de um Framework Transversal Genrico
A idia de um FT com essa arquitetura permitir que as variabilidades
escolhidas/implementadas por meio da especializao realizada na parte (c), sejam acopladas
*
* * *
(d)
(a) (b)
(c)
Indi rectAccess
<<hook>> returnGetMethodInChargeOfGetti ngData()
<<hook>> returnSet MethodInChargeOfSetti ngData()
Wi thReturn
Wi thoutParameters
getJoi nPoi ntObj ect()
Wi thTwoParameters
Target
getObj ect()
Thi s
getObj ect()
Args
getObj ect()
<<hook>> getArgumentPosi ti on()
MyComposi ti onStrategy
returnVari abi l i tyCl assInstance()
returnGetMethodInChargeOfGetti ngVal ue()
returnSetMethodInChargeOfSetti ngVal ue()
OneArgument
Di rectAccess
Aspect
getObject()
<<hook>> returnVari abi l i tyCl assInstance()
StrategyCl ass
Strategy1 Strategy2 Strategy3
MyStrategy
Conj unto de Juno
Abstrato
*

56
a um cdigo-base que identificado pelas regras de composio fornecidas pelos aspectos
criados na parte (d). Por exemplo, a classe MyStrategy representa que a variabilidade
escolhida foi a Estratgia nmero 1 (classe Strategy1), e que ela ser acoplada a algum
cdigo-base utilizando a alternativa de composio This (aspecto This), por meio das regras
de composio definidas no aspecto MyCompositionStrategy.
Geralmente, a parte que trata das variabilidades projetada com padres de projeto j
conhecidos, como o Strategy, Factory Method e/ou Template Method (Gamma et al., 1995).
Como a implementao desses padres com orientao a objetos pode causar problemas de
entrelaamento e espalhamento, aspectos tambm podem ser usados para projetar essa parte
(Hanemann e Kiczales, 2002). Entretanto, deve-se inicialmente averiguar as vantagens e
desvantagens dessa deciso em termos de separao de interesses e de modularidade. Por
exemplo, o padro Strategy apresenta benefcios em termos de separao de interesses, mas
no em modularidade (Garcia et al., 2005).
Do lado direito superior da Figura 3.5, representado pela letra (b), mostrado o
diagrama de projeto genrico do padro. Toda a hierarquia do padro baseada em duas
formas de obteno do dado requerido: direta, representada por meio do aspecto
DirectAcces, e indireta, representada pelo aspecto IndirectAccess. A forma direta
consiste em alternativas de composio que capturam o dado desejado sem a necessidade de
ao reflexiva, isto , o valor obtido diretamente a partir do ponto de juno, por exemplo a
chamada de um mtodo que retorna o valor desejado (aspecto WithReturn). A forma
indireta ocorre por meio de algum objeto intermedirio, isto , primeiramente obtm-se um
objeto do contexto de execuo, por exemplo o target ou o this, e a partir dele obtm-se
reflexivamente o valor desejado, por meio dos mtodos-gancho,
getGetMethodInChargeOfGettingData e getSetMethodInChargeOfSettingData,
pertencentes ao aspecto IndirectAccess. Alguns esteretipos utilizados nesse modelo
facilitam a documentao e a identificao dos pontos de extenso do framework, como, por
exemplo, o esteretipo <<hook>>, que representa mtodos-gancho que devem ser
sobrepostos pelo engenheiro de aplicao (Fontoura et al., 2002).
A nota anexada ao aspecto Aspect mostra a existncia de um conjunto de juno
abstrato, que deve ser definido durante o processo de reso. Esse conjunto de juno deve ser
projetado adequadamente dentro da estrutura do framework para garantir, tanto quanto
possvel, que as regras de composio entrecortem somente os pontos de juno permitidos.
Isso deve ser feito para preservar a integridade do comportamento da aplicao e do
framework, justamente quando regras de composio no adequadas so fornecidas. Por
57
exemplo, nada impede que o engenheiro de aplicao fornea uma regra de composio que
entrecorte chamadas de todos os mtodos em todas as classes do sistema. Isso causaria um
funcionamento incorreto do framework que poderia danificar o sistema. Se diretrizes de
projeto forem seguidas (Camargo et al, 2004) e idiomas forem utilizados (Hanenberg e
Schimidmeier, 2003a; Hanenberg e Schimidmeier, 2003b), como o Composit Pointcut e o
Template Advice, esses problemas podem ser amenizados.
As letras (c) e (d) da Figura 3.5 representam esquematicamente como ocorre o
processo de reso. A etapa de instanciao feita somente na parte OO e a etapa de
composio na parte que possui os aspectos, separando fisicamente essas duas etapas. Cada
aspecto criado na etapa de composio especfico de uma classe criada na etapa de
instanciao, pois o mtodo-gancho returnVariabilityClassInstance() deve ser
implementado pelo engenheiro de aplicao com o objetivo de retornar uma instncia da
subclasse criada. Essa abordagem de projeto se aproxima de algumas abordagens orientadas a
aspectos em que as regras de composio so informadas separadamente do comportamento
transversal, como por exemplo JBoss-AOP, AspectWerkz e JAML (JAML, 2004).
Muitas vezes a utilizao desse padro tambm impe uma ordem no processo de
reso, pois os nomes das sub-classes criadas na etapa de instanciao podem ser utilizados na
etapa de composio, j que cada variabilidade escolhida possui pelo menos um aspecto
correspondente.
Um detalhe interessante de projeto ocorre na hierarquia do aspecto
WithoutParameters. Esse aspecto utiliza o mtodo abstrato getJoinPointObject()
para obter um objeto do contexto de execuo que possa ser utilizado para capturar o dado
desejado. Esse mtodo redefinido em cada um dos aspectos especializados (This, Target e
Args) com o objetivo de retornar diferentes objetos do contexto de execuo, fornecendo
assim trs alternativas de composio. Na Figura 3.6 mostrado parcialmente o cdigo fonte
dos aspectos WithoutParameters e This. O adendo do aspecto WithoutParameters
utiliza o mtodo abstrato getJoinPointObject() para obter um objeto do contexto de
execuo a partir do ponto de juno passado por parmetro. Esse objeto pode ser o target, o
this ou um argumento, dependendo do aspecto que foi especializado. Esse mtodo
implementado nos aspectos Target, This e Args, retornando o objeto apropriado, como
pode ser visto no cdigo do aspecto This. Se o adendo do aspecto WithoutParameters
no utilizasse esse mtodo abstrato, ele deveria fixar o objeto capturado do contexto, o que
restringiria bastante as chances de acoplamento do framework. Por exemplo, se o objeto
capturado fosse sempre o target, as regras de composio fornecidas pelo engenheiro da

58
aplicao deveriam sempre identificar no cdigo-base um ponto de juno cujo objeto target
fosse o objeto ideal, o que pode no acontecer em muitas situaes.

Figura 3.6 Exemplo de Implementao do Padro

O projeto mostrado na Figura 3.5 possui os elementos (aspectos, conjuntos de juno e
mtodos abstratos) bsicos para se projetar um FT. Entretanto, outros elementos podem ser
adicionados nessa hierarquia de acordo com o problema e o interesse transversal que est
sendo encapsulado. Tambm ressalta-se que em determinadas situaes no necessrio
aplicar o padro em sua totalidade, podendo-se remover partes da hierarquia, evitando assim
trechos de cdigos desnecessrios na aplicao final.
As alternativas do padro formam um conjunto de opes para o acoplamento quando se
necessita capturar dados do cdigo-base. Elas tambm podem ser vistas como interfaces de
entrecorte que requerem determinadas propriedades para o acoplamento (Griswold et al.,
2006). Elas foram identificadas com base na experincia com o desenvolvimento de FTs e
estudo de trabalhos relacionados, mas nada impede que novas alternativas sejam necessrias,
principalmente quando o acoplamento for feito com cdigos-base j existentes. Nesse caso, o
engenheiro de aplicao pode criar novas alternativas estendendo os aspectos mais genricos
da hierarquia, como por exemplo o DirectAccess ou o IndirectAccess. As novas
alternativas criadas podem ser includas no padro caso sejam solues para problemas
recorrentes.
Embora cada classe dessa hierarquia mostrada na Figura 3.5 represente um aspecto, esse
padro tambm pode ser implementado como uma hierarquia de classes, desde que uma
public abstract aspect WithoutParameters extends IndirectAccess {

...
after(): obtainValue (){
...

object = getJoinPointObject(thisJoinPoint);

...
}

public abstract Object getJoinPointObject(JoinPoint joinPoint)
}

public abstract aspect This extends WithoutParameters {

public Object getJoinPointObject(JoinPoint joinPoint){

return joinPoint.getThis();

}
}

59
hierarquia de aspectos correspondentes seja mantida. Como os FTs desenvolvidos no contexto
desta tese so projetados como temas, se houver interesse que a hierarquia do padro fique
explcita no modelo, ela deve ser implementada com classes.
Uma propriedade interessante de um FT projetado com esta arquitetura que ele pode
ser instanciado mais de uma vez para uma mesma aplicao ou cdigo-base, isto , diferentes
variabilidades podem ser escolhidas para atuarem em pontos de juno diferentes ou iguais no
mesmo cdigo-base. Quando atuam no mesmo ponto de juno deve haver algum mecanismo
que controle a precedncia de atuao dos aspectos, como por exemplo o declare
precedence da linguagem AspectJ. Na prxima seo mostrado um exemplo que reusa o
FT mais de uma vez para a mesma aplicao.
Outro ponto interessante a analisar so as possibilidades de acoplamento permitidas
com o uso do padro:
1. (1:1) Quando uma variabilidade acoplada ao cdigo-base utilizando uma nica
alternativa de composio. Neste caso, cada classe que representa uma variabilidade
acoplada ao cdigo-base usando uma nica alternativa de composio. Note-se que pode
haver mais de um aspecto correspondente classe, porm o mais comum que haja
apenas um, e que as regras de composio fornecidas atuem em vrios pontos.
2. (1:N) Quando uma variabilidade acoplada ao cdigo-base com mais de uma alternativa
de composio. Neste caso a classe que representa a variabilidade ter mais de um
aspecto correspondente, em que cada um especializa uma alternativa diferente de
composio.
3. (N:1) Quando vrias variabilidades utilizam uma mesma alternativa de composio.
Neste caso cada classe de variabilidade tambm possui um aspecto correspondente,
porm todos eles utilizam a mesma alternativa de composio, isto , especializam o
mesmo aspecto do framework.
4. (N:N) Quando vrias variabilidades utilizam vrias alternativas de composio. Ocorre
quando as possibilidades de acoplamento 1:N e N:1 ocorrem simultaneamente no
mesmo reso do framework.
Depois que o processo de reso foi completado e que o sistema final foi obtido, deve-
se decidir por manter ou eliminar as alternativas de composio que no foram utilizadas. Por
exemplo, se o framework foi reusado em um sistema que utilizou as alternativas
WithoutParameters, OneArgument e WithReturn (Figura 3.5), pode-se decidir por
eliminar a hierarquia do aspecto WithoutParameters. Essa deciso depende da natureza da
aplicao que foi desenvolvida, pois se ela possui uma alta probabilidade de mudana de

60
requisitos interessante que essas alternativas permaneam na arquitetura do framework, pois
ser mais fcil instanciar uma nova variabilidade caso a alternativa de composio j exista. A
hierarquia do padro no possui muito cdigo e no causa muitos problemas de degradao de
desempenho caso permaneam no sistema.
3.3.J- Lxemplo de Utilizao do Padro Capturador de Dados
Com o objetivo de exemplificar a utilizao do padro Capturador de Dados e o processo de
reso de um FT, ser mostrado nesta seo um estudo de caso que faz uso de um dos FTs
desenvolvidos no contexto desta tese: o FT de Clculo Baseado em Tabela. Esse framework
modulariza uma regra de negcio que tem o objetivo de incrementar ou decrementar um valor
capturado do cdigo-base por meio de um clculo percentual, o qual depende da faixa em que
o valor capturado se enquadra. Esse clculo pode ainda fazer uso de um redutor, que um
valor fixo que ser subtrado do clculo percentual. Regras de negcio tpicas que podem ser
tratadas por esse framework so: um valor de vale-refeio que pode ou no ser acrescido ao
salrio do funcionrio dependendo de sua faixa salarial; um desconto na conta de gua para
usurios cujo consumo esteja, por exemplo entre 11 e 15 m
3
e um bnus para funcionrios
cujo nmero de horas extras mensal superior a 30. A estrutura da tabela utilizada no clculo
fixa, mas os valores podem variar conforme a regra de negcio em uso. Na Tabela 3.3
mostrada a estrutura da tabela e valores para o clculo do imposto de renda, que tambm
uma das regras de negcio que pode ser tratada por esse framework e que faz uso do redutor.
Tabela 3.3 Tabela do Framework de Regra de Negcio para o Clculo do Imposto de Renda
Base de clculo Porcentagem Redutor
At R$ 1.164,00 0 0
De RS 1.164,01 a R$ 2.326,00 15% R$ 176,60
Acima de R$ 2.326,00 27,5% R$ 465,35

O modelo de projeto do framework de clculo baseado em tabela pode ser visto na
Figura 3.7. Os aspectos esto sendo representados apenas ilustrativamente por classes em
cinza. Os mtodos que possuem o esteretipo <<hook>> so abstratos e devem ser estendidos
pelo engenheiro da aplicao. Esse esteretipo auxilia a documentar o framework, facilitando
a identificao dos pontos de extenso (Fontoura et al, 2002).
Este FT possui quatro variabilidades funcionais e seis alternativas de composio. A
instanciao deve ser feita por meio das classes abstratas WithoutDeductible e
WithDeductible, a primeira deve ser escolhida quando a regra de negcio possui um
redutor e a segunda quando no possui. Para fazer a instanciao o engenheiro de aplicao
deve criar uma subclasse que representa a regra de negcio que se deseja tratar, definir seus
61
construtores e implementar o mtodo-gancho isIncrement(), o qual permite escolher o
algoritmo de incremento ou de decremento. Deve ser criada uma subclasse e uma tabela no
banco de dados para cada regra de negcio a ser tratada pelo framework. Caso seja de
interesse do engenheiro de aplicao, uma nova variabilidade pode ser adicionada na
hierarquia especializando-se a classe Calculation.

Figura 3.7 Modelo de Projeto do FT de Clculo Baseado em Tabela

Como descrito anteriormente, a etapa de composio consiste em duas atividades:
identificao dos pontos de juno e fornecimento das regras de composio. Para identificar
o(s) ponto(s) de juno mais adequado(s) deve-se analisar nas especificaes do framework o
que ele requer dos pontos de juno e verificar quais so as alternativas de composio
disponveis. No caso deste framework, o importante que por meio do ponto de juno
escolhido seja possvel obter o valor que ser submetido ao clculo da regra de negcio.
Como h vrias formas de se obter esse valor deve-se analisar as alternativas de composio
do framework para identificar como cada uma delas obtm o valor e procurar um ponto de
juno adequado. Com isso, pode-se decidir que ponto de juno ser fornecido na regra de
composio e, assim, qual ser a forma de captura do valor, se por meio de um mtodo que
retorna o valor, se por meio de um objeto que possui o valor, ou alguma outra forma. As seis
alternativas de composio disponveis podem ser vistas na Tabela 3.4. Note-se que essa
tabela a instanciao da tabela genrica (Tabela 3.1) para o contexto do FT de Clculo.
Padro de composio
TBTarget
getJoinPointObject()
TBThis
getJoinPoi ntObj ect()
TBArgs
getArgumentPosition()
Wit hout Deduct ibl e
applyCalculation()
WithDeductible
deductible
applyCalculation()
TBIndi rectAcces
performCalculation(Object)
<<hook>> getSetMethodInChargeOfSettingValue()
<<hook>> getGetMethodInChargeOfGettingValue()
TBOneStringArgument
performCalculation(String)
TBWithoutParameters
<<hook>> getJoinPointObject(JoinPoint) : Object
performCalculation()
Calculation
applyCalculation()
calculateNewValueBasedOnThis()
<<hook>> isIncrement()
TableBasedCalculation
<<hook>> getVariabilityInstance() : Calculation
<<hook>> getValueType() : String
TBWithParameters
getObj ect()
<<hook>> getIndexOfArgs()
TBWithReturn
performCalculation(float)
TBDirectAccess

62
O fornecimento das regras de composio deve ser feito criando-se aspectos
especializados que correspondem a cada regra de negcio tratada, isto para cada subclasse
de WithoutDeductible e/ou WithDeductible. Os aspectos que podem ser estendidos
pelo engenheiro de aplicao so: TBTarget, TBThis, TBArgs, TBWithParameters,
TBOneStringArgument e TBWithReturn, os quais representam cada uma das alternativas
de composio do padro mostrado na Tabela 3.4. A criao desses aspectos tambm exige a
implementao de alguns mtodos-gancho, como, por exemplo,
getVariabilityInstance(), que um mtodo-gancho do aspecto
TableBasedCalculation. Esse mtodo deve retornar o nome da classe que representa a
regra de negcio tratada, fazendo uma correspondncia com a subclasse que foi criada na
etapa de instanciao. Corresponde ao mtodo returnVariabilityClassInstance() do
aspecto Aspect mostrado na Figura 3.5. A implementao do mtodo
getVariabilityInstance() um fator que determina a ordem do processo de reso
deste framework. Como o nome da classe retornada determinado na etapa de instanciao,
no seria possvel realizar a composio antes da instanciao.
Tabela 3.4 Alternativas de Composio do FT de Clculo Baseado em Tabela
Nome Descrio
Com Retorno
(WithReturn)
Esta alternativa consiste em estender o aspecto TBWithReturn e fornecer um ponto de juno cujo retorno o valor
ser modificado. Esse ponto de juno pode ser tanto uma chamada, quanto a execuo de um mtodo.
This
Esta alternativa consiste em estender o aspecto TBThis e fornecer um ponto de juno que a partir do seu objeto this
pode-se obter o valor a ser modificado. Tambm deve ser possvel atribuir o valor modificado a esse mesmo objeto.
Esse ponto de juno pode ser uma chamada ou execuo de um mtodo, ou o acesso a um atributo.
Target
Semelhante alternativa anterior, porm o aspecto a ser estendido o TBTarget e objeto target do ponto de juno
fornecido que ser utilizado para obteno e atribuio do valor modificado.
Args
Semelhante s duas alternativas anteriores, porm o aspecto a ser estendido o TBArgs e o primeiro argumento do
ponto de juno fornecido que ser utilizado para obteno e atribuio do valor modificado.
Com
parmetros
Esta alternativa consiste em estender o aspecto TBWithParameters e fornecer um ponto de juno com dois
parmetros, em que o primeiro parmetro um objeto que pode ser utilizado para obter o valor a ser modificado, e o
segundo objeto dever poder receber o valor modificado.
interessante destacar que o projeto mostrado na Figura 3.7 evidencia algumas
caractersticas da definio de FTs apresentada na Seo 3.2. Por exemplo, a existncia de
mecanismos de composio abstratos e conjuntos de juno. As variabilidades so tratadas
por classes normais. A diviso semntica entre escolha de variabilidades e composio
mantm-se fisicamente separada neste projeto, em que a primeira etapa feita por meio de
classes e a segunda por meio de aspectos. Alm disso, pode-se perceber que no possvel
instanciar este framework sem um cdigo-base, o que no ocorre com os FAOAs.
Ressalta-se tambm que o processo de escolha de alternativas de composio pode
incluir uma atividade de excluso das alternativas que no foram escolhidas, deixando a
aplicao apenas com o cdigo que estritamente necessrio. Por exemplo, caso a alternativa
de composio TBWithReturn tenha sido utilizada, toda a hierarquia do aspecto
63
TBWithoutReturn e inclusive ele, poderiam ser eliminados, facilitando manutenes e no
sobrecarregando o cdigo objeto com trechos no executveis. Alm disso, o FT pode ser
projetado com um sub-conjunto das alternativas de composio existentes, como o caso dos
FT de Persistncia e de Segurana que sero mostrados na prxima seo.
Para ilustrar o reso de FTs projetado com o padro, foi desenvolvido um sistema de
oficina de aparelhos eletrnicos. Esse sistema inclui um sub-sistema de pessoal que controla a
remunerao dos funcionrios, alm de realizar o fechamento mensal e gerar a folha de
pagamento. O salrio-base varia conforme a funo que exercem na oficina. O clculo do
salrio mensal ocorre com base em eventos variveis, eventos fixos e dedues legais que
ocorrem durante o ms. Os eventos variveis podem ser, por exemplo: uma falta, algumas
horas de atraso, determinadas comisses e horas extras. Um exemplo de evento fixo o
clculo do valor do vale-refeio e um exemplo de uma deduo legal o imposto de renda.
O clculo do imposto de renda segue as regras definidas na Tabela 3.3 e o clculo do vale-
refeio as definidas na Tabela 3.5. A diferena entre essas regras que o clculo do imposto
de renda uma regra de decremento com redutor, enquanto que o do vale-refeio de
incremento sem redutor.
Tabela 3.5 Tabela para Clculo do Vale-Refeio
Base de clculo Porcentagem
At R$ 600 10%
De R$ 600,01 a RS 1.000,00 8%
Acima de R$ 1.000,01 5%

O framework de clculo baseado em tabela foi utilizado para tratamento das regras de
negcio referentes ao vale-refeio e ao imposto de renda. Na Figura 3.8 mostrado esse FT
acoplado ao sub-sistema de pessoal. Novamente os aspectos esto sendo representados por
classes destacadas na cor cinza e os relacionamentos de dependncia que partem dos aspectos
myIncomeTax e MyMealTicket em direo s classes PayRoll e Employee representam
que esses aspectos entrecortam pontos de juno dessas classes. Para economizar espao, na
parte superior da figura mostrada apenas uma parte do FT apresentado pela Figura 3.7. Na
parte intermediria so mostradas as classes e aspectos criados pelo engenheiro de aplicao
durante o processo de reso e na parte inferior as classes do sistema de pessoal.
A instanciao feita estendendo-se as classes WithoutDeductible e
WithDeductible. Assim, as classes IncomeTax (Imposto de renda) e MealTicket
(vale-refeio) foram criadas para representar as regras de negcio que devem ser tratadas. Na
Figura 3.9 mostrado o cdigo fonte dessa segunda classe com os mtodos que ela deve
conter, isto , com dois construtores, um vazio e um normal, e o mtodo isIncrement(),
que permite escolher um dos algoritmos alternativos do framework.

64
Como mencionado anteriormente, a etapa de composio consiste em identificar os
pontos de juno apropriados no cdigo-base e escolher a alternativa de composio mais
adequada. O ponto de juno que foi identificado no cdigo-base para a composio da regra
de clculo do vale-refeio mostrado na Figura 3.10. O mtodo apresentado responsvel
por efetuar o fechamento mensal com base nos eventos fixos e variveis do funcionrio. O
clculo realizado por este mtodo inicia obtendo o valor do salrio-base da funo exercida
pelo funcionrio e prossegue realizando acrscimos e dedues baseados nos eventos
variveis ocorridos durante o ms.

Figura 3.8 Framework de Clculo Baseado em Tabela Instanciado

Figura 3.9 Escolha de Variabilidades

Figura 3.10 Ponto de Juno na Aplicao
public class MealTicket extends WithoutDeductible {

public MealTicket() { }
public MealTicket(...) { super (...); }
public boolean isIncrement(){ return true; }

public void calculateMySalaryBasedOnEvents(int month, int year){
...
this.lastSalary = this.getFunction().getBaseSalary().getValue();

for (int i =0; i < eventsOfThisMonth.size(); i++){

event = (Event)eventsOfThisMonth.elementAt(i);
...
}

Ponto de Junao Lscolhido
lramework
Instanciaao -
Composiao
Aplicaao
TBTarget
getJoinPoi ntObject()
TBThis
getJoinPoi nt Object()
TBArgs
WithoutDeductible
applyCalculation()
WithDeductible
deduct ibl e
applyCalculat ion()
TBWithReturn
performCal culati on(float)
TBOneStringArgument
performCalculation(String)
EventComission
value
EventOverTime
EventAbsence
EventDelay
PayRoll
closingDat e
mont lyClosi ng()
Meal Ti cket
isIncrement()
IncomeTax
isIncrement()
MyMeal Ticket
getValueType()
getNameOfTableClassWithPackage()
myIncomeTax
getNameOfTableClassWithPackage()
getValueType()
getGetMethodInChargeOfReturningValue()
getSetMethodInChargeOfSettingValue()
Event
ID
date
getEventType()
isType()
equals()
toString()
Employee
name
lastSalary
registerEvent()
calculateMySalaryBasedOnEvents()
getEventsOfThisMonth()
Function
ID
description
BaseSalary
value
beginDate
finalDate
65
Assumindo-se que o valor do vale-refeio deve ser acrescido ao salrio do
funcionrio antes dos descontos legais, este um bom momento para realizao do clculo.
Portanto, foi identificado que por meio da chamada do mtodo getValue() o valor do
salrio-base poderia ser capturado com a alternativa de composio com retorno, j que
esse mtodo retorna o valor sujeito ao clculo. Assim, foi criado o aspecto MyMealTicket
(Figura 3.11), que estende o aspecto TBWithReturn e que permite compor a regra de
negcio de clculo do vale-refeio (representada pela classe MealTicket) com o cdigo-
base.

Figura 3.11 Aspecto da Regra de Negcio de Clculo do Vale-Refeio

Na Figura 3.11 mostrado o cdigo do aspecto MyMealTicket. Como definido na
especificao do framework, quando se utiliza a alternativa de composio Com Retorno, o
ponto de juno fornecido pelo engenheiro de aplicao deve ser uma chamada ou execuo
de um mtodo que retorne o valor a ser modificado. Portanto, a regra de composio definida
entrecorta chamadas ao mtodo getValue() da classe BaseSalary originadas do mtodo
calculateMySalaryBasedOnEvents() da classe Employee, como representado pela
dependncia entre o aspecto MyMealTicket e a classe Employee na Figura 3.7. Essas
chamadas retornam o valor do salrio-base do funcionrio, que o valor a ser modificado
com base na tabela de vale-refeio. Nesse mesmo aspecto, o mtodo
getNameOfTableClassWithPackage() tambm deve ser implementado para informar ao
framework o nome da classe que representa a regra de negcio a ser considerada. Isto ,
quando a chamada ao mtodo getValue() acontecer, a regra de negcio que deve ser
aplicada definida pela classe MealTicket. A implementao do mtodo
getValueType() tambm obrigatria pois define o tipo primitivo do valor que ser
modificado.
A existncia de um ponto de juno que retorne o valor desejado a situao ideal de
acoplamento, como ocorreu no exemplo acima. Entretanto, isso pode no ocorrer e, neste
caso, uma outra alternativa de composio deve ser escolhida. Por exemplo, o acoplamento da
regra de negcio de clculo do imposto de renda foi feito com a alternativa sem parmetro
public aspect MyMealTicket extends TBWithReturn {

public pointcut obtainValue():
call (* BaseSalary.getValue())
&& withincode (* Employee.calculateMySalaryBasedOnEvents(int, int));
public String getNameOfTableClassWithPackage(){
return "tableBasedCalculation.instantiation.MealTicket";
}
public String getValueType(){ return "float";}
}


66
(target), pois no havia um ponto de juno no cdigo-base que retornasse o salrio que
base para esse clculo. Na Figura 3.12 mostrado o ponto de juno que foi utilizado para
essa composio. Essa linha de cdigo pertence a um mtodo do sistema de folha de
pagamento responsvel por efetuar o fechamento mensal. Utilizando a alternativa de
composio sem parmetro (target) o framework captura o objeto employee e usa
reflexividade para capturar e alterar o valor do salrio.
Note-se que a utilizao de reflexividade fundamental para bons projetos de
acoplamento, principalmente para frameworks que necessitam obter valores da aplicao.
Geralmente a obteno desses valores no to simples e o responsvel pelo fornecimento
das regras de composio deve ter conhecimento dos pontos de juno adequados e de como
esses valores podem se capturados.

Figura 3.12 Ponto de Juno para o Acoplamento do Imposto de Renda
Os clculos do imposto de renda e do vale-refeio so apenas exemplos concretos de
possveis instanciaes do framework de clculo baseado em tabela. Em sistemas de grande
porte o clculo generalizado por este framework pode ser utilizado por outras regras de
negcio, com caractersticas prprias e que podem ou no ser temporrias. O uso do mesmo
clculo a partir de vrios pontos do sistema torna o cdigo de diferentes interesses espalhado e
entrelaado. Alm disso, como geralmente as regras de negcio tendem a se alterar com muito
mais freqncia do que a funcionalidade do sistema, mant-las em mdulos separados traz
benefcios para modularidade e, conseqentemente, para a manuteno.
Um ponto que pode ser questionado se a implementao do interesse mostrado nesta
seo factvel com aspectos, ou se deveria ser implementado de forma convencional com
orientao a objetos. Nesse sentido, h dois fatores que devem ser analisados. O primeiro a
volatilidade do interesse, isto , sua probabilidade de mudana. Visto que regras de negcio,
como imposto de renda e vale-refeio tem alta probabilidade de mudana durante o tempo de
vida do sistema, sua implementao com tcnicas que facilitem a remoo e incluso no
cdigo-fonte, como a POA, pode ser uma estratgia que apresente benefcios durante a
manuteno do sistema.
Outro fator quanto transversalidade do interesse. As regras de negcio mostradas
nesta seo no so transversais, j que cada uma afeta apenas um ponto de juno do cdigo-
base. Contudo, embora as regras de negcio em si no sejam transversais, o algoritmo
utilizado por ambas as regras o mesmo, e utilizado, portanto, em dois locais do cdigo. O
...
employee.calculateMySalaryBasedOnEvents(initialDate.getMonth(),2004);
...
67
sistema utilizado como estudo de caso de pequeno porte, entretanto, um sistema de grande
porte poderia utilizar esse mesmo algoritmo em vrios locais do cdigo para o tratamento de
regras de negcio diferentes, caracterizando o algoritmo como transversal. Assim, argumenta-
se que, embora algumas regras de negcio especficas no sejam transversais, os algoritmos
utilizados para tratamento dessas regras podem ser, o que justifica sua implementao de
forma genrica e conseqentemente com POA.
3.4 - CONSIDLRALS IINAIS
O objetivo neste captulo foi analisar o panorama atual da literatura de FTs e propor uma
homogeneizao com relao aos termos e arquitetura utilizada no desenvolvimento desses
softwares. A ausncia de termos bem definidos prejudica o crescimento da rea gerando
dvidas sobre o que realmente um determinado software. Um exemplo disso a utilizao
do termo framework orientado aspectos para designar frameworks completamente
diferentes.
A arquitetura proposta para FTs deve auxiliar desenvolvedores na criao de FTs
dependentes de contexto com uma arquitetura mais clara e padronizada. A utilizao do
padro Capturador de Dados auxilia no fornecimento de alternativas de composio, cujo
objetivo prover formas alternativas de acoplamento com um cdigo-base. A adoo de uma
arquitetura padro tambm se torna particularmente importante quando famlias de FTs
devem ser criadas.
No Captulo 4 apresentado o repositrio desenvolvido no contexto desta tese como
famlias de FTs. Assim linhas de produtos de FTs so definidas permitindo a configurao de
diversos FTs com caractersticas distintas. Uma particularidade dessas famlias a
implementao de caractersticas como FTs, o que facilita o acoplamento e o desacoplamento
com uma caracterstica-base. Alm disso, a implementao de caractersticas como
frameworks propicia seu reso tambm fora de sua linha de produtos original.


68

Captulo 4

av t i a. ae r ave ror/. 1r av.rer .ai .
Neste captulo, os FTs desenvolvidos no contexto desta tese so apresentados na forma de trs
famlias: persistncia, segurana e regras de negcio. Cada famlia caracteriza uma linha de
produtos de FTs para um determinado interesse. Cada linha de produtos possui caractersticas
tambm implementadas na forma de FTs que podem ser usadas durante a configurao de
membros da famlia. Com o objetivo de exemplificar a estrutura e a forma de utilizao de
uma famlia, o FT de persistncia e o de Segurana so discutidos detalhadamente.
Na Seo 4.2 fornecida uma viso geral das famlias de FTs desenvolvidas no
contexto desta tese. Na Seo 4.3 mostrada uma linha de produtos de FTs de persistncia e
como utiliz-la. Na Seo 4.4 discute-se, com um nvel de detalhes menor, uma linha de
produtos de FTs de segurana e na Seo 4.5 so apresentadas as consideraes finais.
4.2 IAMLIAS DL IRAMLWORKS 1RANSVLRSAIS
Na Tabela 4.1 so apresentados os FTs desenvolvidos no contexto desta tese. A primeira
coluna divide os FTs em trs famlias: persistncia, segurana e regras de negcio, de acordo
com o interesse que eles implementam. Dentro das famlias de Persistncia e Segurana h
FTs de nvel mais alto e FTs de nvel mais baixo. Os FTs de nvel mais alto esto destacados
em cinza e s podem ser acoplados diretamente a uma aplicao, pois somente neste nvel
que suas funcionalidades podem ser utilizadas. J os FTs de nvel mais baixo foram
projetados de forma que possam ser acoplados a outros FTs ou outros interesses que estejam
implementados ou no com aspectos.
Captulo 4 Famlias de Frameworks Transversais

70
Tabela 4.1 Frameworks Transversais
avtia ^o. 1 Proce..o ae Rev.o .ttervatira. ae covo.iao 1ariabitiaaae. fvvciovai.
Conscincia total*
1
Operaes
Persistentes
Instanciao/ composio Padro
Conscincia parcial
Driver nativo
Driver de ODBC*
mySql*
Interbase
2 Conexo
Instanciao,
composio
Padro
SyBase
Com retorno*
Target
This
Args
3
Memria
auxiliar
Carregador
de Objetos
Composio
Com parametros
No
Com retorno*
Target
This
Args
4
Memria
auxiliar
Todas
Tuplas
Composio
Com parametros
No
Com retorno
This*
Target
5 Pooling Composio
Args

No
Checagem de Atributos
P
e
r
s
i
s
t
n
c
i
a

6
Garantia de
Polticas
Composio Padro
Checagem de mtodos sets e gets
Target
This 7 Autenticao Composio
Args
No
8
Controle de
acesso
Composio Padro No
This
Target
Args
9
Registro de
acessos
Instanciao, Composio
Com parmetros*
No
Com retorno* Erros sucessivos*
S
e
g
u
r
a
n
a

10
Polticas de
Bloqueamento
Target Erros no sucessivos
Reajuste linear para todas categorias
Reajuste linear para categorias especficas 11
Reajuste de
valor
Instanciao, Composio Padro
Reajuste No linear
Com retorno
Sem parmetro (this)
Incremento com redutor
Sem parmetro (target)
Incremento sem redutor
Sem parmetro (args)
Decremento com redutor
Com parmetros R
e
g
r
a
s

d
e

N
e
g
c
i
o

12
Clculo
baseado em
tabela
Um argumento

Decremento sem redutor

Na famlia Regras de Negcio h apenas dois FTs de nvel mais alto que so
exemplos de requisitos transversais funcionais implementados como aspectos. Na Seo 3.3.1
o FT de Clculo Baseado em Tabela foi utilizado para exemplificar a utilizao do padro
Capturador de Dados e por isso no ser discutido neste captulo. H na literatura algumas
menes ao uso de aspectos para a codificao de regras de negcios (Suve et al., 2005;
Cibrn et al., 2003; Cibrn et al., 2006), mas no foram encontradas publicaes que
apresentam exemplos de implementao de aspectos desse tipo na forma de FTs.
Os FTs de nvel mais baixo foram projetados como funcionalidades e/ou
variabilidades dos FTs de nvel mais alto, podendo ser vistos como caractersticas do FT de
nvel mais alto. Por exemplo, o FT de memria auxiliar, pode ser visto como uma
caracterstica do FT de persistncia. Assim, cada famlia uma linha de produtos de FTs, em
que vrios FTs podem ser gerados com determinadas configuraes (Gomma, 2004). Vale
71
ressaltar que embora os FTs de nvel mais baixo tenham sido projetados de forma genrica,
no foi realizado nenhum estudo de caso para averiguar seu reso fora da linha de produtos
original.
A quarta coluna da Tabela 4.1 classifica cada FT com relao ao seu processo de
reso, mostrando que alguns possuem apenas a etapa de composio. A separao por uma
barra indica que as duas etapas podem ser feitas em paralelo e a vrgula representa que o
processo seqencial.
A quinta coluna contm as alternativas de composio que alguns frameworks
possuem. Para alguns deles apenas uma forma de composio suficiente, representada como
Padro. J para os FTs dependentes de contexto, a existncia de mais de uma alternativa
necessria, o que justifica a aplicao completa ou parcial do padro Capturador de Dados.
Como pode ser visto, alguns FTs utilizam as seis alternativas de composio do padro
enquanto que outros no. Por exemplo, o FT de clculo baseado em tabela foi projetado com
todas as alternativas, porm o mesmo no ocorre com o de pooling e o de polticas de
autenticao. A deciso de utilizar completamente ou parcialmente o padro depende das
caractersticas do interesse transversal implementado pelo FT.
Os FTs que possuem mais de uma alternativa de composio geralmente possuem uma
alternativa default (representada por um asterisco), que ser utilizada caso nenhuma outra seja
escolhida. Isso normalmente ocorre com FTs que so caractersticas de outros FTs. Por
exemplo, como o FT de Pooling uma caracterstica do FT de persistncia (Camargo et al.,
2003), j existe uma alternativa de composio escolhida e conseqentemente, uma regra de
composio pr-definida com o framework de persistncia. Isso implica que quando o FT de
pooling escolhido para ser utilizado em uma aplicao que usa o framework de persistncia,
no ser necessrio fornecer regras de composio para o acoplamento, ser necessrio apenas
adicionar esse FT no projeto. Na sexta coluna tambm possvel encontrar asteriscos
representando variabilidades default.
Na sexta coluna so apresentadas as variabilidades funcionais de cada FT, sejam eles
do nvel de aplicao ou do nvel de frameworks. Note-se que alguns FTs no possuem
variabilidades funcionais, como por exemplo o FT de Controle de Acesso.
4.3 IAMLIA DL IRAMLWORKS 1RANSVLRSAIS DL
PLRSIS1LNCIA
O FT de persistncia desenvolvido no contexto desta tese (Camargo et al., 2003), assim como
outros frameworks de persistncia orientados a objetos, como Hibernate (2006), Cayenne

72
(2006) e OJB (2006), tem como objetivo facilitar o desenvolvimento de uma aplicao
orientada a objetos que utiliza banco de dados relacional. Os mecanismos necessrios para
tratar as incompatibilidades entre os dois paradigmas (relacional e orientado a objetos) so
implementados pelo framework e podem ser reusados durante o desenvolvimento de novas
aplicaes. Esse FT uma evoluo de um trabalho anterior (Camargo et al., 2003; Ramos et
al., 2004) e possui como base o padro de projeto Camada de Persistncia (Persistence Layer)
(Yoder et al., 1998).
O FT consiste em duas partes com objetivos distintos e que foram implementadas em
mdulos distintos. A primeira parte, chamada de operaes persistentes, um conjunto de
operaes de persistncia que devem ser herdadas por classes de aplicao persistentes e que
podem ser utilizadas para armazenar, remover, atualizar e realizar consultas no banco de
dados. A estratgia de implementao adotada no projeto do FT foi introduzir todas as
operaes de persistncia em uma interface e fazer com que as classes de aplicao
persistentes
19
implementem essa interface. A maioria das operaes de persistncia
disponibilizada pelo FT pode ser vistas na Tabela 4.2. Essas operaes constituem a interface
disponibilizada pelo FT para a aplicao.
Por causa da diversidade de situaes que podem ocorrer em um sistema, no h
garantia que o nmero de operaes providas pelo FT seja suficiente para apoiar a
implementao de qualquer sistema. Antecipar todas as funcionalidades um problema j
constatado por vrios pesquisadores (Fayad, 2000; Johnson e Foote, 1988; Johnson e Russo,
1991). Assim, um ponto importante que o FT seja extensvel, isto , que permita que o
engenheiro de aplicao possa criar novas operaes. Na Seo 4.3.2 so mostradas trs
formas de adaptao para o FT de persistncia.
A segunda parte, chamada de conexo, referente ao interesse de conexo com o
banco de dados, que tem como objetivo identificar locais do cdigo-base em que a conexo
deve ser aberta e fechada. A primeira parte depende da segunda para conseguir executar as
operaes de persistncia.

19
Uma classe de aplicao persistente uma classe cujos objetos devem ser persistidos em alguma tabela do
banco de dados. Cada classe de aplicao persistente possui uma tabela correspondente no banco de dados com o
mesmo nome da classe.
73
Tabela 4.2 Operaes do FT de Persistncia
Assinatura da Operao Descrio
public int getNextID()
Utilizada para retornar o prximo ID disponvel na tabela do banco de
dados que representada pela classe do objeto alvo.
public boolean save()
Utilizada para armazenar o objeto alvo da chamada em sua respectiva
tabela do banco de dados. Retorna true se a operao foi realizada
com sucesso.
public boolean delete()
Utilizada para remover o objeto alvo da chamada de sua respectiva
tabela do banco de dados. Retorna true se a operao foi realizada
com sucesso.
public ResultSet findlike()
Utilizada para localizar e recuperar o objeto alvo no banco de dados. Se
o objeto foi encontrado, retorna um ResultSet com os dados desse
objeto, caso contrrio retorna um ResultSet vazio.
public ResultSet findlikeByField
(String columnName, String columnValue)
Utilizada para recuperar todos os registros da tabela do banco de dados,
representada pela classe do objeto alvo, que a coluna columnName
tenha o valor String columnValue.
(String columnName, int columnValue)
representada pela classe do objeto alvo, que a coluna columnName
tenha o valor columnValue do tipo int.
(String columnName, FrameworkDate
columnValue){
Utilizada para recuperar todos os registros da tabela representada pelo
objeto alvo que a coluna columnName tenha o valor columnValue
do tipo FrameworkDate.
(String columnName1, String columnName2,
String columnValue1, String columnValue2){
representada pela classe do objeto alvo, que a coluna columnName1
tenha o valor String columnValue1 e que a coluna columnName2
tenha o valor String columnValue2.
Integer columnValue1, Integer
columnValue2){
representada pela classe do objeto alvo, que a coluna columnName1
tenha o valor Integer columnValue1 e que a coluna
columnName2 tenha o valor Integer columnValue2.
(String tableName, String
columnParameterName, Integer
parameterValue){
Utilizada para recuperar todos os registros da tabela tableName, que
coluna columnName tenha o valor columnValue.
public ResultSet findlike
(String columnName, FrameworkDate
columnValue){
Utilizada para recuperar todos os registros da tabela representada pelo
objeto alvo que a coluna columnName tenha o valor columnValue
do tipo FrameworkDate.
public ResultSet
findlikeByField_intervalOfDates
String columnName3, String columnName4,
Integer columnValue1, FrameworkDate
initialDate, FrameworkDate finalDate,
Integer columnValue2){
Utilizada para recuperar os registros da tabela representada pela classe
do objeto alvo que a coluna columnName1 tenha o valor
columnValue1 e que a coluna columnName2 tenha o valor
initialDate, e que a coluna columnName3 tenha o valor finalDate
e que a coluna columnName4 tenha o valor columnValue2.
public ResultSet
findlikeByField_intervalOfDates
String columnName3, Integer columnValue,
FrameworkDate initialDate, FrameworkDate
finalDate){
Utilizada para recuperar todos os registros da tabela representada pela
classe do objeto alvo em que a coluna columnName1 tenha o valor
columnValue e que a coluna columnName2 tenha um valor maior ou
igual a initialDate e que a coluna columnName3 tenha um valor
menor ou igual a finalDate.
public static ResultSet findAll()

Utilizada para recuperar todos os registros da tabela representada pela
classe do objeto alvo. Retorna um ResultSet com todos os registros.
public Object setDBToObject(ResultSet)
Utilizada para preencher o objeto alvo da chamada com os valores
disponveis no ResultSet. Essa operao retorna um objeto que deve
ser convertido (Cast) para algum tipo especfico da aplicao.
public Object setDBToObject()

Utilizada para preencher o objeto alvo da chamada com seus
respectivos valores de sua respectiva tabela do banco de dados. Similar
operao anterior, porm sem a necessidade de passar um
ResultSet por parmetro. O ID do objeto alvo deve possuir um valor
antes que essa operao possa ser utilizada.

Como j comentado por alguns pesquisadores, alguns interesses no podem ser
implementados de forma totalmente ortogonal ao interesse-base de um sistema, como caso
da persistncia (Rashid and Chitchyan, 2003), da concorrncia e do gerenciamento de falhas

74
(Kienzle e Guerraoui, 2002). No caso da persistncia, durante o desenvolvimento da aplicao
necessrio ter conscincia de algumas operaes. As operaes que tratam de
armazenamento e atualizao podem ser completamente tratadas pelo FT e assim, podem ser
negligenciadas durante o desenvolvimento de um sistema. Por exemplo, pode-se implementar
um aspecto que armazena um objeto no banco de dados sempre que o construtor desse objeto
for executado. Tambm pode ser implementado um aspecto de atualizao, que entrecorta as
chamadas aos mtodos que modificam os valores dos atributos (sets) e realizam as
atualizaes no banco de dados. Note-se que, nesses dois casos, h pontos de juno
adequados que podem ser entrecortados, independentemente da linguagem de programao
utilizada.
O mesmo no ocorre com as operaes de remoo e busca, pois elas devem ser
explicitamente chamadas em momentos definidos pelo engenheiro da aplicao. Quando a
linguagem Java utilizada, no h pontos de juno adequados no cdigo-base que podem ser
entrecortados para a remoo de um objeto. Um possvel ponto de juno para a remoo de
um objeto seria sua destruio, isto , quando o seu destrutor executado. Porm, no caso da
linguagem Java isso feito pela JVM (Java Virtual Machine) em momentos no
determinsticos. Isso pode ser solucionado quando uma outra linguagem, por exemplo C,
utilizada. Contudo, as operaes de busca continuam com o problema.
Em virtude dessa particularidade do interesse de persistncia, o FT foi implementado
com as variabilidades de Conscincia Total e Conscincia Parcial, diferentemente do
framework de persistncia apresentado por Rashid e Chitchyan (2003), que possui apenas a
estratgia Conscincia Parcial. Quando a primeira estratgia utilizada, o engenheiro de
software responsvel por invocar todos os mtodos de persistncia disponibilizados pelo FT
(Tabela 4.2), enquanto que na segunda, esse profissional deve se preocupar apenas com as
operaes de remoo (delete()) e busca (findlike()).
Alm da prpria natureza do interesse, a forma como ele implementado tambm
influencia na conscincia (obliviousness) que o cdigo-base possui de sua existncia. Por
exemplo, para o correto funcionamento do FT de Persistncia, as seguintes polticas devem
ser seguidas durante o desenvolvimento do cdigo-base:
1. Toda classe de aplicao persistente deve possuir construtores com e sem
parmetros;
2. Cada classe de aplicao persistente deve ter uma tabela correspondente no banco
de dados com o mesmo nome da classe;
75
3. Toda classe de aplicao persistente deve possuir mtodos de acesso aos atributos
(sets e gets);
4. Cada atributo de uma classe de aplicao persistente deve possuir uma coluna na
tabela correspondente no banco de dados com o mesmo nome do atributo.
5. Todo mtodo que altera um atributo do tipo int deve receber um parmetro do
tipo Integer.

Essas polticas de implementao podem ser vistas como contratos que devem ser
seguidos para o correto funcionamento do FT (Griswold, et al., 2006). Mais frente ser
mostrado o FT de Garantia de Polticas, o qual foi desenvolvido para verificar se duas dessas
polticas existem no cdigo-base.
Na Figura 4.1 mostrado um diagrama de caractersticas que representa a linha de
produtos de FTs de Persistncia seguindo a notao proposta por Gomma (2004). Algumas
caractersticas foram implementadas como FTs, mas tambm h outras que foram
implementadas como aspectos normais e com mecanismos tradicionais da orientao a
objetos, como mtodos e classes abstratas. Apenas a ttulo de ilustrao, as caractersticas
implementadas como FTs/aspectos esto destacadas em cinza. A nica caracterstica
implementada como aspecto normal a conscincia parcial (Partial), que est destacada com
uma nota.

l

Figura 4.1 Diagrama de Caractersticas da Linha de Produtos de FTs de Persistncia
As caractersticas Operaes Persistentes (Persistent Operations) e Conexo
(Connection), ambas implementadas como FTs, so comuns a todos os membros da linha de
{mutually exclusive feature} {mutually exclusive feature}
ODBC
<<default feature>>
Native
<<alternative feature>>
InterBase
SyBase
<<default feature>>
MySQL
Caracterstica
implementada como
um nico aspect o
Partial
Total
<<default feature>>
AllObjects
<<optional feature>>
ObjectLoader
ColNames
ConnectionType
<<exactly-one-of feature group>>
DataBase
Awareness
Cache
<<zero-or-more-of feature group>>
Pooli ng
<<opti onal feature>>
Connection
<<common feature>>
requi res
requires
Persistent Operations
<<common feature>>
mutually includes requires
requires
mut ually includes
Utilizado durante o
desenvolvimento ou
evoluo
GetSetChecker
PolicyEnforcement
<<zero-or-more-of feature group>>
requires
AttributeChecker

76
produtos e representam as operaes de persistncia que devem ser inseridas nas classes de
aplicao persistentes e o interesse de conexo com o banco de dados, respectivamente.
Assim, a etapa de instanciao do FT de persistncia consiste em escolher as variabilidades da
caracterstica Operaes Persistentes e tambm da Conexo. Essa a configurao mnima do
FT de Persistncia, j que as demais caractersticas so opcionais. Embora os FTs de
Operaes Persistentes e Conexo estejam sendo mostrados como duas caractersticas,
poderiam ser representados em apenas uma, j que ocorrem sempre juntos nos membros da
linha de produtos. Em virtude disso, no decorrer do texto o termo FT de Persistncia
utilizado para representar essas duas caractersticas.
O FT Operaes Persistentes possui duas variabilidades Total e Parcial que se
encontram agrupadas sob o grupo de caractersticas Conscincia (Awareness). Uma dessas
variabilidades deve, obrigatoriamente, estar presente em qualquer membro da linha de
produtos, como destaca o esteretipo <<exactly-one-of feature group>>. Entretanto se o
engenheiro de software responsvel pelo desenvolvimento no realizar a escolha, a alternativa
Total ser automaticamente adotada. A Conexo, por sua vez, possui dois grupos de
caractersticas Connection Type e DataBase que tambm devem ter uma de suas
variabilidades obrigatoriamente escolhidas.
As caractersticas de Repositrio de Conexes e Memria Auxiliar so opcionais e
podem ser utilizadas para melhorar o desempenho do FT de persistncia. A caracterstica
Garantia de Polticas (Policy Enforcement) um FT usado geralmente apenas durante o
desenvolvimento para testar se as seguintes duas polticas exigidas pelo FT de Persistncia
esto presentes no cdigo-base: presena de mtodos de acesso aos atributos nas classes de
aplicao persistentes e existncia de atributos com o mesmo nome das colunas da tabela do
banco de dados correspondente a uma determinada classe de aplicao persistente (Rocha et
al., 2004a; Rocha et al., 2004b), que constituem suas duas variabilidades. Esse FT ser
mostrado com mais detalhes na Seo 4.3.4.
Todas as caractersticas implementadas como FTs contm camada de pr-composio,
o que feito para facilitar a adoo da caracterstica em um novo membro da linha de
produtos, sem a necessidade, ou minimizando o trabalho, de instanciao e composio. Por
exemplo, a caracterstica de Memria Auxiliar Object Loader est implementada como um
FT. Embora essa caracterstica esteja projetada como um framework, visando seu reso em
outros contextos, dentro da linha de produtos que provavelmente ela ser mais utilizada.
Assim, a existncia a camada de pr-composio j fornece o cdigo de acoplamento com
esse FT.
77
Na Figura 4.2 mostrado um diagrama que representa ilustrativamente as classes e
aspectos que compem as caractersticas Operaes Persistentes e Conexo, distinguidas
pelas formas geomtricas com linhas tracejadas. Nessa figura, os aspectos esto sendo
representados por retngulos destacados em cinza, e os relacionamentos de associao que
partem dos aspectos para alguma entidade representam que o aspecto afeta a entidade
entrecortando (crosscutting) a execuo/chamada de seus mtodos ou introduzindo (inter type
declaration) operaes, por meio de declaraes intertipo. Os demais relacionamentos
possuem semntica convencional da UML. Um sub-conjunto do perfil UML-F (Fontoura et
al., 2002) est sendo usado para evidenciar os ganchos que devem ser sobrepostos pelo
engenheiro de aplicao. Todos os mtodos com o esteretipo <<hook>> so abstratos e
devem ser sobrepostos pelo engenheiro de aplicao em classes concretas. Esse pefil
utilizado em todos os outros FTs desenvolvidos no contexto desta tese.

Figura 4.2 Estrutura do Framework Transversal de Persistncia
A classe TableManager responsvel por montar dinamicamente as declaraes
SQL e executar as operaes de persistncia. Para que essa classe seja capaz de executar os
comandos de persistncia ela possui uma dependncia com o FT de conexo que no est
sendo mostrada. No framework de persistncia proposto por Soares (Soares, 2004), as
declaraes SQL so implementadas de forma fixa dentro do sistema. O aspecto
DirtyObjectsController responsvel por marcar objetos que foram alterados em
memria para que essas alteraes sejam refletidas no disco em momentos apropriados. um
TableManager
ColumnHandler
SyBaseConnection
MySQLConnection InterbaseConnection
DBSpecificConnectionDetail
userName
password
ConnectionManager
<<hook>> setSpecificDatabase()
setSpecificDB()
executeQuery()
conectDB()
disconnectDB()
OdbcConnection
<<hook>> setDSN()
ConnectDB()
closeDB()
connect()
do_connect()
NativeConnection
connect DB()
closeDB()
DefaultConnection
setSpecificDatabase()
strategy
ConnectionComposition
PartialAwareness PersistentEntities
DirtyObjectsController
OORelati onal Mapping PersistentRoot
findAll()
findLike()
save()
setDBToObj ect()
getPrimaryKeyValue()
getPrimaryKeyClause()
getGetMethods()
getSetMethods()
setColValues()
...
<< Interface>>
crosscutts
crosscutts
inter type declaration
crosscutts
Operaes Persistentes
Conexo

78
exemplo de um sub-interesse de persistncia que foi implementado como um aspecto fixo
dentro da arquitetura do framework.
Em relao ao FT Operaes Persistentes, a utilizao de aspectos ocorre em dois
pontos distintos. Durante o processo de reso do FT, ao invs de realizar modificaes
invasivas em todas as classes de aplicao, introduzindo a declarao implements
PersistentRoot em todas elas, um aspecto deve ser criado para fazer isso utilizando
declaraes intertipo da linguagem AspectJ. Esse aspecto concreto, que deve ser criado pelo
engenheiro de software deve estender o aspecto abstrato PersistentEntities, cujo
cdigo est sendo mostrado parcialmente na Figura 4.3. Esse aspecto introduz na interface
PersistentRoot um conjunto de atributos e operaes de persistncia que ser herdado
pelos sub-tipos dessa interface. Como j comentado, esses sub-tipos so classes de aplicao
que devem possuir correspondncia com o banco de dados e so determinadas pelo
engenheiro de aplicao em tempo de reso.

Figura 4.3 Cdigo do Aspecto PersistentEntities
O segundo ponto importante em que aspectos so utilizados na realizao do
mapeamento com o banco de dados, que feito internamente pelo FT quando os objetos das
classes que so sub-tipos da interface PersistentRoot so criados. Assim, ao invs do
cdigo do mapeamento estar dentro do construtor de cada uma das classes, ele est
encapsulado no aspecto OORelationalMapping, mostrado parcialmente na parte superior
da Figura 4.4. Esse aspecto define comportamento adicional no construtor de cada objeto sub-
tipo da interface PersistentRoot quando esses construtores so executados. O objetivo
inserir em cada um desses objetos meta-informaes sobre sua correspondncia com o banco
de dados, como por exemplo: o nome da tabela correspondente, o nmero de colunas da
tabela e o nome dessas colunas.
public abstract aspect PersistentEntities {

public String PersistentRoot.tableName = "";
public String PersistentRoot.keyName = "";
...

private void PersistentRoot.setTableName(String t){...}

private void PersistentRoot.setTableName(){...}

public boolean PersistentRoot.save () {...}

private Vector PersistentRoot.getPrimaryKeyValue(){...}

public PersistentRoot PersistentRoot.setDBToObject(ResultSet rs){...}

...
79
Note-se que os conjuntos de juno utilizados pelos adendos do aspecto
OORelationalMapping esto no aspecto XOORelationalMapping. Esse aspecto, que
est sendo mostrado na parte inferior da Figura 4.4, representa a interface de entrecorte
dinmica do aspecto OORelationalMapping, e segue a forma de implementao sugerida
por Griswold et al. (2006). Essa estratgia desacopla o comportamento do aspecto de sua
interface, facilitando evolues paralelas e distintas de ambas as partes. Note-se tambm que
essa interface dinmica no visvel durante o processo de reso do FT, pois ela se encontra
na estrutura interna do FT.

Figura 4.4 Cdigo do Aspecto OORelationalMapping

A implementao do FT Operaes Persistentes utiliza os idiomas Marker Interface e
Container Introduction propostos por Hanenberg e Schimidmier (Hanenberg and
Schimidmeier, 2003a). A interface PersistentRoot assume tanto o papel de
MarkerInterface quanto de Container e o aspecto PersistentEntities assume o papel de
ContainerIntroduction. A utilizao desses idiomas faz com que os aspectos internos do FT,
public aspect OORelationalMapping
{
ColumnHandler columnHandler;

after (PersistentRoot pr):
XOORelationalMapping.topLevelJoinPointFullConstructor(pr) {
columnHandler = new ColumnHandler();

pr.setTableName();

pr.setColNames(columnHandler.returnColNames(pr.getTableName()));

...
}

after (PersistentRoot pr):
XOORelationalMapping.topLevelJoinPointEmptyConstructor(pr)
{
...
}
...
}
public aspect XOORelationalMapping {

private pointcut joinPointFullConstructor(PersistentRoot pr):
target(pr) && execution(PersistentRoot+.new(*,..));

private pointcut joinPointEmptyConstructor(PersistentRoot pr):
execution (PersistentRoot+.new()) && target(pr);

public pointcut topLevelJoinPointFullConstructor(PersistentRoot pr):
joinPointFullConstructor(pr) &&
execution((!PersistentRoot).new(*,..));

public pointcut topLevelJoinPointEmptyConstructor(PersistentRoot pr):
joinPointEmptyConstructor(pr) &&
execution ((!PersistentRoot).new());
}


80
por exemplo, o OORelationalMapping, possuam dependncia apenas com a interface
PersistentRoot, evitando dependncia com nomenclaturas utilizadas na aplicao.
Em relao caracterstica de Conexo, o nico aspecto existente o
ConnectionComposition, que responsvel por entrecortar pontos de juno do cdigo-
base, possivelmente uma aplicao, e utilizar os mtodos connectDB() e disconnectDB()
da classe ConnectionManager para abrir e fechar conexes com o banco de dados, como
mostrado na Figura 4.5. Os pontos de juno devem ser fornecidos pelo engenheiro de
aplicao por meio da criao de um aspecto concreto que estende o aspecto
ConnectionComposition em tempo de composio.

Figura 4.5 Aspecto ConnectionComposition
A escolha das variabilidades da conexo feita estendendo-se uma das classes filhas
de ConnectionManager. Note-se na Figura 4.2 a existncia de uma classe abstrata chamada
DefaultConnection. Essa classe responsvel por definir as variabilidades padro para a
conexo, que consiste em uma conexo feita via ODBC do Windows com banco de dados
MySQL. Caso a conexo padro seja escolhida, o responsvel pelo desenvolvimento deve
estender diretamente essa classe do FT de conexo. Se alguma outra variabilidade for
desejada, basta estender qualquer das outras classes.
A etapa de composio da maioria dos FTs com algum cdigo-base feita por meio de
regras de composio que operam dinamicamente. Todavia, no caso do framework de
public abstract aspect ConnectionComposition {

private ConnectionManager connectionManager;

public abstract pointcut openConnection();
public abstract pointcut closeConnection();

public ConnectionComposition(){

Class c = Class.forName(getNameOfConnectionVariabilitiesClass());
connectionManager = (ConnectionManager)c.newInstance();
...
}

before() : openConnection()
{
connectionManager.ConnectDB();
...
}

after():closeConnection(){

connectionManager.DisconnectDB();
...
}

public abstract String getNameOfConnectionVariabilitiesClass();

}
81
persistncia, particularmente em relao as Operaes Persistentes, a composio feita por
meio de regras de composio estticas, que operam em tempo de compilao. Isso ocorre
com maior freqncia em FTs que modularizam interesses que no podem ser totalmente
negligenciados durante o desenvolvimento da aplicao.
4.3.J Processo de Reso do I1 de Persistncia
O processo de reso do FT de Persistncia, que consiste em acopl-lo a uma determinada
aplicao, possui as etapas de instanciao e de composio. Na instanciao, trs
variabilidades precisam ser determinadas: o tipo da conscincia (Total ou Parcial), o tipo da
conexo com o banco de dados (ODBC ou driver nativo) e o prprio banco de dados. Na
etapa de composio necessrio informar quais so as classes de aplicao persistentes e
quais os locais do cdigo-base em que a conexo deve ser aberta e fechada. Esses passos so
o mnimo necessrio para se acoplar o FT de persistncia a um cdigo-base.
A adio de caractersticas, como Memria Auxiliar e Repositrio de Conexes, pode
ser feita antes ou depois que o FT for acoplado a um cdigo-base. Neste exemplo mostrado
primeiro o acoplamento do FT de persistncia a uma aplicao hipottica e depois a
caracterstica de pooling adicionada. No framework de segurana que ser mostrado adiante,
essa ordem de acoplamento ser invertida.
Para escolher a variabilidade conscincia parcial basta que o aspecto
PartialAwareness, mostrado parcialmente na Figura 4.6 seja adicionado ao projeto. Esse
aspecto uma caracterstica especfica do FT de persistncia, por isso ele j tem
conhecimento dos pontos que devem ser entrecortados, no havendo necessidade de
concretizao por parte do engenheiro de software. Como pode ser observado, esse aspecto,
assim como outros FTs desenvolvidos, utiliza o idioma Composite Pointcut (Hanenberg e
Schimidmeier, 2003a; Hanenberg e Schimidmeier, 2003b).
Para escolher a variabilidade conscincia total, basta no adicionar o aspecto
PartialAwareness no projeto, j que essa variabilidade a default, como pode ser visto no
digrama de caractersticas mostrado na Figura 4.1.
A escolha das variabilidades da conexo feita estendendo-se uma das classes filhas
de ConnectionManager (Figura 4.2). Caso a classe DefaultConnection, mostrada na
Figura 4.7, seja estendida, a configurao padro da conexo ser escolhida, bastando apenas
que o usurio informe o nome do DSN criado no painel de controle do Windows em uma
classe concreta que estenda DefaultConnection.
Na Figura 4.8 mostrada a modelagem do FT de Persistncia como um tema
transversal (Clarke e Baniassad, 2005), representando o FT depois da etapa de instanciao.

82
Note-se que o FT de Conexo j se encontra instanciado com sua variabilidade padro
(default), o que representado pela classe myConnectionVariabilities. Essa classe
deve ser criada pelo engenheiro de aplicao com o objetivo de retornar o nome do DSN
criado no painel de controle do Windows.

Figura 4.6 Cdigo do Aspecto PartialAwareness

Figura 4.7 Classe DefaultConnection
Esse tema deve ser composto com um cdigo-base para adicionar as operaes de
persistncia (disponveis na interface PersistentRoot) em classes de aplicao persistentes
e tambm para identificar pontos do cdigo-base em que a conexo deve ser aberta e fechada,
o que caracteriza os passos da etapa de composio. A lista de gabaritos no canto superior
esquerdo do pacote mostra dois mtodos-gabarito. O primeiro representa pontos de juno do
public aspect PartialAwareness{

pointcut excludedJoinPoints():
!call(public void PersistentRoot+.setID(..)) &&
!call(public void PersistentRoot+.setTableName(..)) &&
!call(public void PersistentRoot+.setKeyName(*)) &&
...

pointcut update(PersistentRoot pr):
target(pr)
&& call (public void (PersistentRoot+ && !PersistentRoot).set*(*))
&& excludedJoinPoints();

pointcut save(PersistentRoot pr):
target(pr)
&& execution ((PersistentRoot+ && !PersistentRoot).new(*, ..));

pointcut saveOrUpdate(PersistentRoot pr):
save(pr) || update(pr);

after(PersistentRoot pr): saveOrUpdate(pr){
try
{
if (pr.save()){
System.out.println("All right !);
}else{

throw new PartialAwarenessException(pr);
}

}catch(StoringException e){
...

}}}

import persistence.connection.*;

public abstract class DefaultConnection extends OdbcConnection {

public String setSpecificDatabase(){
return "mysql";
}
}
83
cdigo-base em que a conexo deve ser aberta e o segundo pontos em que a conexo deve ser
fechada. Os dois diagramas de seqncia mostram o comportamento do FT para cada um
desses mtodos-gabarito. Note-se que a abertura da conexo ocorre antes do comportamento
original do mtodo que ser entrecortado, enquanto que o fechamento ocorre depois.
Na Figura 4.9 mostrado como deve ser o projeto da composio com uma aplicao
hipottica. Por questes de legibilidade, a parte superior da figura mostra o tema transversal
de persistncia apenas com as classes significativas para a composio. As setas tracejadas
que ligam a classe BaseClass com algumas classes de aplicao representam que essas
classes so correspondentes e que sero fundidas, fazendo com que as classes de aplicao
assumam o lugar da BaseClass depois da composio dos dois temas. Assim, as operaes
existentes na interface PersistentRoot sero herdadas por essas classes de aplicao.

Figura 4.8 Framework de Persistncia como um Tema Transversal
Persistence
<AppClass.pointToOpenConnection()>
<AppClass.pointToCloseConnection()>
appClass : AppClass : Connecti onManager
point ToCloseConnect ion()
do_PointToCloseConnection( )
disconnectDB( )
myConnectionVariabilities
setDSN()
SyBaseConnection
OdbcConnection
<<hook>> setDSN()
ConnectDB()
closeDB()
connect()
do_connect()
NativeConnection
connectDB()
closeDB()
TableManager
PersistentRoot
findAll()
findLike()
save()
setDBToObject()
...
<< interface>>
userName
password
ConnectionManager
setSpecificDB()
executeQuery()
conectDB()
disconnectDB()
strategy
AppClass
pointToOpenConnection()
do_pointToOpenConnection()
pointToCloseConnection()
do_pointToCloseConnection()
Def aultConnecti on
ColumnHandl er
BaseClass
appClass : AppClass : Connecti onManager
pointToOpenConnection()
connectDB()
do_pointToOpenConnection()

84

Figura 4.9 Composio do FT de Persistncia com uma Aplicao
O relacionamento de ligao entre os dois pacotes contm dois conjuntos de operaes
que sero mapeados para os dois gabaritos do tema transversal. O primeiro conjunto de
mtodos, que consiste em uma srie de mtodos init(), so locais da aplicao adequados
para abrir a conexo, e o segundo, que consiste em uma srie de mtodos destroy(), so
locais adequados para fechar a conexo.
A implementao correspondente ao modelo mostrado na Figura 4.9 consiste em
estender o aspecto PersistentEntities e declarar quais so as classes de aplicao
persistentes, o que deve ser feito por meio de declaraes intertipo da linguagem AspectJ. Na
Figura 4.10 mostrado um trecho de cdigo do aspecto MyPersistentEntities que
uma especializao do aspecto PersistentEntities e que declara que as classes
Employee, Function e Event so sub-tipos da interface PersistentRoot. Fazendo isso,
os objetos dessas classes agora dispem de operaes de persistncia para armazenar
(save()), remover (delete()), atualizar (update()) e localizar (find*()) registros no
banco de dados.
Persistence <AppClass.pointToOpenConnection()>
Application
Event
ID
date
getEventType()
isType()
equals()
toString()
Employee
name
lastSalary
registerEvent()
calculateMySalaryBasedOnEvents()
getEventsOfThisMonth()
Function
ID
description
Regist erOfEvent s
main()
<<main>>
srvRegisterOfEmployees
init()
destroy()
RegisterOfFunction
init()
destroy()
bind [<{srvRegisterOfEmployees.init(), RegisterOfFunction.init(),
RegisterOfEvents.main()}>
<{srvRegisterOfEmployees.destroy(), RegisterOfFunction.destroy(),
RegisterOfEvents.main()}>]

PersistentRoot
findAll()
findLike()
save()
setDBToObject()
...
<< interface>>
BaseClass
85
Depois que o FT de Operaes Persistentes foi composto, resta fazer o mesmo com a
Conexo. A Figura 4.11 mostra o aspecto MyConnectionComposition, que representa a
composio da Conexo com o cdigo-base. Note-se que os mtodos descritos no
relacionamento de ligao da Figura 4.9 so os pontos de juno do cdigo-base que devem
ser afetados. Note-se tambm que o mtodo
getNameOfConnectionVariabilitiesClass() deve ser concretizado pelo engenheiro
de aplicao para retornar o nome da classe criada na etapa de instanciao.

Figura 4.10 Composio do Framework de Persistncia com Classes de aplicao persistentes

Figura 4.11 Aspecto MyConnectionComposition

A Figura 4.12 mostra o modelo resultante da composio entre os dois temas
mostrados anteriormente. A classe BaseClass foi substituda pelas classes Event,
Employee e Function, representando que essas classes agora implementam a interface
PersistentRoot e, conseqentemente, herdam as operaes de persistncia.
A classe gabarito AppClass foi substituda pelas classes
srvRegisterOfFunction, srvRegisterOfEmployees e RegisterOfEvents,
representando que os mtodos init() e destroy() das duas primeiras classes e o mtodo
main() da ltima, so afetados pelo interesse de conexo. Os diagramas de seqncia
mostram o novo comportamento do mtodo init() e do mtodo destroy() da classe
srvRegisterOfEmployees. Os retngulos posicionados atrs dos diagramas de seqncia
public aspect MyPersistentEntities extends PersistentEntities {

declare parents: Employee implements PersistentRoot;
declare parents: Function implements PersistentRoot;
declare parents: Event implements PersistentRoot;
}

public aspect MyConnectionComposition extends ConnectionComposition {

public pointcut openConnection(): execution (* srvCadastro*.init(..))
|| execution (* srvRegisterOfEmployees.init(..))
|| execution (* srvRegisterOfFunction.init(..))
|| execution (* RegisterOfEvents.main(..));

public pointcut closeConnection() :
execution (* srvRegisterOfEmployees.destroy(..))
|| execution (* srvRegisterOfFunction.destroy(..))
|| execution (* srvRegisterOfEvents.main(..));

public String getNameOfConnectionVariabilitiesClass(){
return "persistenceInstantiation.myConnectionVariabilities";
}


86
representam que outros diagramas de seqncia tambm foram gerados para os outros
mtodos entrecortados. Por questes de legibilidade, os relacionamentos entre as classes de
aplicao foram suprimidos.
Um detalhe importante de desenvolvimento que as classes de aplicao persistentes
precisam ser projetadas e implementadas seguindo as seguintes convenes exigidas pelo FT.
Aconselha-se que a deciso por utilizar ou no o FT de persistncia seja feita logo no incio
do processo, para que modificaes no sejam necessrias depois que as Operaes
Persistentes j estiverem implementadas. As convenes exigidas so:

Figura 4.12 Modelo de Composio Resultante
myConnecti onVari abi lit ies
setDSN()
SyBaseConnection
OdbcConnecti on
<<hook>> setDSN()
ConnectDB()
closeDB()
connect()
do_connect()
Nat iveConnect ion
connectDB()
closeDB()
DefaultConnection
ColumnHandler
TableManager
PersistentRoot
fi ndAll()
fi ndLike()
save()
setDBToObject()
. ..
<< interface>>
userName
password
Event Employee Functi on
srvRegisterOfFunction
ini t()
destroy()
do_init()
do_dest roy()
srvRegist erOfEmpl oyees
init()
destroy()
do_init()
do_destroy()
RegisterOfEvents
main()
do_main()
<<main>>
Connecti onManager
<<hook>> set Specifi cDatabase()
setSpeci ficDB()
executeQuery()
conectDB()
disconnectDB()
strategy
o : srvRegisterOfEmployees : ConnectionManager
init( )
do_init( )
conectDB( )
Application
o : srvRegist erOfEmpl oyees : ConnectionManager
destroy( )
do_destroy( )
disconnectDB( )
87
Toda classe deve possuir um construtor vazio e um normal, sendo que esse ltimo
deve possuir como parmetros todos os atributos da classe;
Todo mtodo set*() que altera um atributo do tipo int, o tipo do parmetro
deve ser Integer, e realizar a converso internamente;
Os relacionamentos de associao com cardinalidade 1 para 1 so representados
por atributos do tipo da classe. Por exemplo, uma classe A possui um relacionamento
de associao com a classe B. Assim, a classe A deve possuir um atributo denominado
b do tipo B;
Os relacionamentos com cardinalidade maior que 1, devem ser implementados
com vetores (classe Vector). Por exemplo, se a classe A possui um relacionamento
de 1 para n com a classe B, ento na classe A deve existir um atributo denominado b
do tipo Vector;
Outra forma de implementao que poderia ter sido adotada para disponibilizar as
operaes de persistncia para as classes de aplicao transformar todas as operaes em
mtodos estticos e introduzi-los em uma classe de fachada, a qual poderia ser utilizada
estaticamente pelas classes de aplicao. Entretanto, considera-se que a forma que foi
utilizada seja mais adequada, pois no h a necessidade de passar para outra entidade a
responsabilidade da persistncia.
4.3.2 Adaptaes no I1 de Persistncia
Durante o desenvolvimento de uma aplicao que utiliza um FT, h um ponto em que
deve-se decidir se o FT pode ser usado como est ou se necessita de adaptaes. No caso do
FT de persistncia, essas adaptaes consistem em verificar se as operaes disponibilizadas
por ele so suficientes ou no para implementar os requisitos. Geralmente essa necessidade
surge quando as operaes disponibilizadas pelo FT devem ser utilizadas como parte do
comportamento de mtodos da aplicao, e isso pode ocorrer durante a elaborao dos
modelos de interao ou mesmo durante a implementao. As operaes do FT de
persistncia que geralmente so adaptadas so as consultas, pois muito difcil antecipar
todos os tipos possveis de consultas no FT.
As adaptaes podem ser de trs tipos: 1) criao de novas operaes; 2) sobreposio
de operaes e 3) empacotamento (wrapping) de operaes. Sugere-se que as adaptaes
sejam feitas no aspecto criado pelo engenheiro de aplicao durante a composio da
persistncia, isto , naquele que estende o aspecto PersistentEntities do framework.
O primeiro tipo de adaptao consiste na criao de novas operaes, como est sendo
mostrado pela Figura 4.13. O mtodo findlike_selectRegistersBetweenDates()

88
uma operao nova criada pelo engenheiro de aplicao para fornecer mais uma opo de
consulta. Todos os mtodos do framework responsveis por executar consultas no banco de
dados seguem o mesmo formato, isto , h um vetor que representa as clusulas SQL e um
outro vetor que representa os parmetros. Depois que as clusulas e os parmetros foram
definidos, deve-se invocar o mtodo findlikeDB() da classe TableManager passando o
nome da Tabela, o vetor de clusulas e o vetor de parmetros. Note-se tambm que os novos
mtodos devem ser introduzidos (por meio de declaraes intertipos) na interface
PersistentRoot.

Figura 4.13 Criao de Novos Mtodos

O segundo tipo de adaptao a sobreposio, que deve ser utilizada quando a
funcionalidade de alguma operao do framework no adequada e deve ser modificada.
Uma caracterstica desse tipo de adaptao que as operaes modificadas continuam com os
mesmos nomes, no exigindo que a equipe de desenvolvimento que j conhece o framework
necessite de treinamento extra. Por exemplo, suponha que no FT exista um mtodo
denominado findlikeByField_intervalOfDates() que retorna registros que se
encontram em um determinado intervalo de datas, incluindo as datas iniciais e finais.
Dependendo das caractersticas do negcio, pode ser que as datas iniciais e finais no
devessem ser includas na consulta. Quando essa situao ocorre pode-se sobrepor o mtodo
do framework, como esta sendo mostrado pela Figura 4.14. Assim, o mtodo continua com o

declare parents: Employee implements PersistentRoot;
declare parents: Function implements PersistentRoot;
declare parents: Event implements PersistentRoot;

...

public ResultSet PersistentRoot.findlike_selectRegistersBetweenDates
(String field1, String field2, String field3, Integer fieldValue,
FrameworkDate initialDate, FrameworkDate finalDate){

Vector clauseV = new Vector();
Vector parameter = new Vector();

clauseV.addElement(field1 + "=");
clauseV.addElement(field2 + ">=");
clauseV.addElement(field2 + "<=");
clauseV.addElement(field3 + ">=");
clauseV.addElement(field3 + "<=");

parameter.addElement(fieldValue);
parameter.addElement(initialDate);
parameter.addElement(finalDate);

return TableManager.findlikeDB_intervalOfDates(this.getTableName(), clauseV,
parameter);

89
mesmo nome do original, porm a montagem do vetor de clusulas no inclui operadores
relacionais >= e <= e sim apenas > e <, para que as datas iniciais e finais no faam parte da
consulta, como feito originalmente.
O terceiro tipo de adaptao o empacotamento, que um caso especial de
sobreposio, pois as operaes tambm continuam com o mesmo nome. A diferena
principal que no caso do empacotamento o comportamento original do framework continua
sendo utilizado, enquanto que na sobreposio ele descartado. O tipo de empacotamento
mostrado aqui difere um pouco de sua definio original, a qual pode mudar o nome do
mtodo. A idia do empacotamento reaproveitar a funcionalidade de uma operao e
adicionar comportamento extra antes ou depois de sua execuo. A forma de empacotamento
sugerida mostrada pela Figura 4.15. A idia criar um adendo do tipo around que entrecorte
chamadas ou execues do mtodo que se deseja empacotar. No corpo desse adendo pode-se
invocar o mtodo original por meio do proceed() e adicionar funcionalidades antes ou
depois de sua execuo. Dessa forma, quando o mtodo original do framework for utilizado,
seu comportamento ser alterado por meio do adendo criado. Tambm podem ser utilizados
adendos do tipo before() e after().

Figura 4.14 Adaptao do Tipo Sobreposio do FT de Persistncia
O empacotamento difere um pouco dos outros tipos de adaptao porque feito com
tecnologia de aspectos. Em se tratando de orientao a objetos, a estratgia de empacotamento
seria sobrepor a operao e invocar seu comportamento original por meio do comando
super(). Entretanto, isso no pode ser feito no framework e por isso necessria a definio
de um adendo.

declare parents: Hotel implements PersistentRoot;
declare parents: Cliente implements PersistentRoot;
...

public ResultSet PersistentRoot.findlikeByField_intervalOfDates(String
field1, String field2, String field3, Integer fieldValue, FrameworkDate
initialDate, FrameworkDate finalDate){

Vector clauseV = new Vector();
Vector parameter = new Vector();

clauseV.addElement(field1 + "=");
clauseV.addElement(field2 + ">");
clauseV.addElement(field3 + "<");

parameter.addElement(fieldValue);

return TableManager.findlikeDB (this.getTableName(), clauseV,
parameter);
}


90
As adaptaes mostradas nas Figuras 4.13, 4.14 e 4.15 consideram que o engenheiro
de aplicao est utilizando um FT caixa preta, em que ele no possui acesso ao cdigo fonte
do framework. Quando o FT caixa branca, as adaptaes podem ser feitas diretamente no
cdigo do framework. Por exemplo, a operao criada na Figura 4.13 poderia ser
implementada no aspecto PersistentEntities, incorporando essa nova operao ao
framework. No caso da sobreposio e do empacotamento, se no houver preocupao em
manter a funcionalidade original do framework, as operaes poderiam ser modificados no
prprio framework.

Figura 4.15 Adaptao do Tipo Empacotamento
4.3.3 Acoplamento de Caracteristicas ao I1 de Persistncia
Como comentado anteriormente, a utilizao das caractersticas pode ser feita antes ou depois
que o FT foi acoplado a uma aplicao. No h uma ordem obrigatria porque as
caractersticas afetam apenas o FT, independentemente de j estar acoplado a um cdigo-base
ou no. Com o objetivo de exemplificar como deve ser realizado o acoplamento de uma
caracterstica com o FT de Persistncia, a caracterstica de Pooling ser utilizada.
O objetivo do Pooling melhorar o desempenho do FT mantendo um repositrio de
conexes. Na Figura 4.16 mostrado o FT de Pooling como um tema transversal. A
hierarquia da classe PoolDataCatcher corresponde implementao do padro Data
Catcher, que utilizado porque a interface desse FT necessita capturar um objeto do tipo
Connection no ponto de juno em que a composio realizada. Esse objeto ser

...

ResultSet around() : call (* PersistentRoot.findlike()){
try
{
ResultSet rs = proceed();
if (rs.getMetaData().getColumnCount() > 5){
return rs;
}
else{
return null;
}
}
catch(SQLException e){
System.out.println("CATCH: MyOORelationalMapping " +
e.getMessage());
return null;
}
}}

91
armazenado em um repositrio de conexes e pode ser usado posteriormente quando novas
conexes forem necessrias.
O diagrama de seqncia mostra que quando o mtodo-gabarito
pointsThatCreateConnection() for executado, a operao empty() verifica se o
repositrio est vazio. Em caso positivo, o comportamento original desse mtodo-gabarito
chamado para criar um novo objeto Connection, que retornado e colocado no repositrio.
Em caso negativo, o objeto Connection que estiver no topo da pilha retornado ao invs de
criar uma nova conexo.

Figura 4.16 FT de Pooling como um Tema Transversal
Como comentado anteriormente, as caractersticas implementadas como FTs possuem
camada de pr-composio. O modelo mostrado na Figura 4.16 faz uso dessa camada
Context BaseClass : ConnectionPool
point sThat CreateConnection()
empty := empty()
connection := do_pointsThatCreateConnection [empty = t rue]
push(connection)
connection := pop [empty = false]
connection
connection
<BaseClass.pointsThatCreateConnection()>
Pooling
TargetPooling
getObj ect()
getNumberOfObjectsToGetFromVector()
ThisPooli ng
getObj ect()
getNumberOfObjectsToGet FromVect or()
WithoutReturnPooling WithRet urnPooli ng
DefaultPooli ng
BaseClass
do_pointsThatCreateConnection()
pointsThatCreateConnection()
ConnectionPool
pool : Stack
push()
pop()
PoolDataCatcher
getObject(JoinPoint : jp)
getNumberOf Object sToGetFromVector()

92
definindo a alternativa de composio This como padro, o que pode ser notado pela
existncia da classe concreta DefaultPooling. Essa alternativa foi definida como padro
porque o acoplamento da caracterstica de Pooling com o FT de Persistncia pode ser feito
com essa alternativa de composio. A alternativa Target tambm mantida para permitir que
esse FT tambm seja reusado fora de sua linha de produtos. Entretanto, apenas com a
experincia de um novo reso que seria possvel determinar as alternativas de composio
necessrias.
Na camada de pr-composio tambm h um aspecto concreto chamado
DefaultPoolingAspect que realiza a composio propriamente dita com o FT de
persistncia. Tanto a classe DefaultPooling quanto o aspecto encontram-se em um pacote
Java separado que devem ser adicionados no projeto somente se o objetivo for o acoplamento
com o FT de persistncia. Caso contrrio, basta no incluir esse pacote no projeto e escolher a
alternativa de composio e um outro ponto de juno de um outro cdigo-base. Vale ressaltar
que as caractersticas que possuem essa camada de implementao tambm possuem os
modelos de projeto da composio prontos.
Na Figura 4.17 mostrado o projeto da composio entre a aplicao (que j foi
acoplada ao FT de Persistncia) e a caracterstica de Pooling. Apenas algumas classes esto
sendo mostradas para facilitar a visualizao. O relacionamento de ligao entre os temas
destaca que o FT de Pooling afeta o FT de persistncia no mtodo connect() da classe
OdbcConnection. O relacionamento de ligao entre os pacotes e a existncia da classe
DefaultPooling representam a camada de pr-composio.
Na Figura 4.18 mostrado o aspecto DefaultPoolingAspect, que realiza a
composio com o FT de Persistncia. Note-se que o mtodo connect() da classe
OdbcConnection, destacado no relacionamento e ligao entre os pacotes da Figura 4.9, o
ponto de juno usado na concretizao do conjunto de juno abstrato poolPushPop() do
aspecto abstrato PoolWithoutReturn.
Alguns mtodos tambm so concretizados para informar detalhes especficos do
cdigo-base. Por exemplo, os mtodos
getMethodResponsibleForSettingTheConnection() e
getMethodResponsibleForGettingTheConnection() so usados internamente pelo
FT de Pooling para conseguir capturar reflexivamente o objeto Connection do contexto de
execuo, como pode ser visto na Figura 4.19. Essa figura mostra parcialmente o cdigo do
aspecto Pool_WithoutReturn. Note-se que o mtodo
returnInstanceOfPoolDataCatcherClass() usado para obter uma instncia da
93
classe DefaultPooling. Isso feito porque essa instncia sabe como obter o objeto do
cdigo-base que contm o objeto Connection desejado, que por meio do objeto This. Esse
objeto uma instncia da classe OdbcConnection, que possui mtodos de acesso ao objeto
Connection, como getConnection() e setConnection(). Se o FT de Pooling fosse
acoplado a um outro cdigo-base esses mesmos mtodos deveriam ser concretizados pelo
engenheiro de aplicao.

Figura 4.17 Acoplamento do FT de Pooling com o FT de Persistncia
Na Figura 4.20 mostrado parcialmente o modelo de projeto composto do sistema,
agora com a caracterstica de Pooling. Note-se que a classe gabarito BaseClass foi
substituda pela classe OdbcConnection do FT de Persistncia.
Esta tese tambm inclui uma proposta de desenvolvimento de software apoiado por
FTs chamado ProFT/PU. Este processo inclui alguns artefatos que devem ser elaborados com
o objetivo de rastrear e controlar o acoplamento dos FTs na aplicao. Dois artefatos
Application
Pooling
<BaseClass.pointsThatCreateConnection()>
bind [<OdbcConnection.connect()>]

BaseClass
do_pointsThatCreateConnection()
pointsThatCreateConnection()
ConnectionPool
pool : Stack
push()
pop()
OdbcConnection
<<hook>> setDSN()
ConnectDB()
closeDB()
connect()
do_connect()
NativeConnect ion
connect DB()
closeDB()
srvRegisterOfFunction
init()
destroy()
do_init()
do_destroy()
srvRegisterOfEmployees
init()
destroy()
do_init()
do_destroy()
ConnectionManager
setSpecificDB()
executeQuery()
conectDB()
disconnectDB()
RegisterOfEvents
main()
do_main()
<<main>>

94
utilizados com esse fim so Viso da Arquitetura e Registro de Pontos de Juno. Esse ltimo
um registro dos aspectos que se encontram acoplados ao sistema e tambm dos pontos de
juno que eles afetam. Esse artefato uma ferramenta conceitual que auxilia a identificar
pontos de juno afetados por mais de um aspecto e se ser necessrio elaborar algum
mecanismo de precedncia de atuao entre eles. Maiores detalhes sobre ProFT/PU e seus
artefatos sero apresentados no Captulo 6.

Figura 4.18 Cdigo Fonte do Aspecto DefaultPoolingAspect

Figura 4.19 Cdigo Fonte do Aspecto PoolWithoutReturn

public aspect DefaultPoolingAspect extends Pool_WithoutReturn {

public pointcut poolPushPop():
execution (public void OdbcConnection.connect(..));

public String getMethodResponsibleForReturningTheConnection(){
return "getConnection";
}
public String getMethodResponsibleForSettingTheConnection(){
return "setConnection";
}
public int getMaxNumberOfConnectionsInThePool(){
return 5;
}
public PoolDataCatcher returnInstanceOfPoolDataCatcherClass(){
return new DefaultPooling();
}
}
public abstract aspect Pool_WithoutReturn extends Pooling {

void around(): pointThatCreatesConnection(){

PoolDataCatcher myPoolDataCatcher = returnInstanceOfPoolDataCatcherClass();

objectHoldingTheConnection = myPoolDataCatcher.getObject(thisJoinPoint);

this.maxNumberOfConnections = getMaxNumberOfConnectionsInThePool();

...

Connection connection =
(Connection)objectHoldingTheConnection.getClass().getMethod(getMethodResponsi
bleForReturningTheConnection(), new
Class[]{}).invoke(objectHoldingTheConnection, new Object[]{});

ConnectionPool.pool.push(connection);

...

}
public abstract PoolDataCatcher returnInstanceOfPoolDataCatcherClass();

public abstract String getMethodResponsibleForReturningTheConnection();
public abstract String getMethodResponsibleForSettingTheConnection();
}

95

Figura 4.20 Modelo de Projeto Composto da Aplicao com a Caracterstica de Pooling

4.3.4 O I1 de Garantia de Politicas
Como comentado anteriormente, a deciso de utilizar o FT de Persistncia em uma
aplicao exige que a aplicao seja desenvolvida seguindo certas polticas ou regras. Essas
polticas podem ser checadas estaticamente, em tempo de compilao, ou dinamicamente, em
tempo de execuo (Eicheberg, et al., 2004). Checagens em tempo de compilao baseiam-se
na anlise esttica do programa e portanto os resultados so vlidos para qualquer execuo
do programa, independentemente dos dados de entrada fornecidos. Algumas checagens, no
my ConnectionVariabilities
setDSN()
NativeConnection
connectDB( )
closeDB()
Connect ionManager
setSpecif icDB()
executeQuery()
conectDB()
disconnectDB()
DefaultConnection
setSpecif ic Databas...
TargetPooling
getObject()
getNumberOf ObjectsToGetFromVec... )
ThisPooling
getObject()
getNumberOf ObjectsToGetFromVec... )
Wi thoutRet urnPooling WithReturnPooling
Def aultPooling
PoolDataCatcher
getObject(JoinPoint : jp)
getNumberOfObjectsToGetFromVector()
ConnectionPool
pool : Stack
push()
pop()
OdbcConnection
<<hook>> setDSN()
ConnectDB()
closeDB()
connect()
do_connect()
Context : OdbcConnection : ConnectionPool
connect( )
connect ion := do_pointsThatCreateConnecti on [empt y = true]
connect ion
connect ion
empty := empty()
push(connection)
connect ion := pop [empty = false]
Application

96
entanto, envolvem valores s disponveis durante a execuo e portanto no podem ser
realizadas dessa forma. As checagens dinmicas, ainda que exijam a execuo do programa,
antecipam potenciais problemas que podem ocorrer posteriormente, durante o funcionamento
do sistema ou que, sob condies especficas, no poderiam ser detectados.
A implementao de um mecanismo que realize essa verificao de propriedades
utilizando apenas orientao a objetos leva ao entrelaamento e espalhamento do cdigo que
implementa esse mecanismo com o cdigo que implementa a funcionalidade do sistema. A
implementao de assertivas usando orientao a objetos um exemplo que ilustra esse
problema.
Com o objetivo de verificar o cumprimento de duas dessas polticas foi criado o FT de
Garantia de Polticas como uma caracterstica opcional da linha de produtos de FTs de
Persistncia (Rocha et al., 2004a; Rocha et al., 2004b). As duas polticas que so verificadas
por esse FT so: a presena de mtodos de acesso aos atributos (sets e gets) e a existncia de
atributos com os mesmos nomes de colunas da tabela do banco de dados, constituindo duas
variabilidades desse FT.
Assim como o FT de Repositrio de Conexes apresentado na seo anterior, o FT de
Garantia de Polticas uma caracterstica opcional do FT de Persistncia, porm com a
diferena que geralmente usado apenas durante o desenvolvimento da aplicao, com o
objetivo de testar os contratos exigidos pelo FT. Isso permite classificar o FT de Garantia de
Polticas com uma caracterstica de desenvolvimento.
Na Figura 4.21 mostrado um modelo de classes, em que cada classe representa um
aspecto do FT de Garantia de Polticas. Os aspectos Pre_weaved_AttributeChecker e
Pre_weaved_GetSetChecker representam a camada de pr-composio com o FT de
Persistncia. Um ponto importante desta camada que ela utiliza os conjuntos de juno da
interface de entrecorte XOORelationalMapping (Figura 4.4) pertencente ao FT de
Persistncia, ao invs de definir novamente os pontos de juno, como pode ser observado na
Figura 4.22. Assim como foi comentado anteriormente, se o objetivo for reusar esse FT em
outros contextos, basta que o engenheiro de software crie aspectos concretos que estendam
diretamente AttributeChecker e GetSetChecker.
O aspecto Checker encapsula o comportamento comum aos dois tipos de checagem e
tambm possui um atributo esttico denominado enabled e um mtodo setEnabled() que
muda o estado desse atributo. O objetivo permitir que o FT possa ser ligado e desligado
durante a execuo da aplicao, recurso til quando a aplicao j foi verificada e no
97
necessita mais de verificao. Tambm pode ser utilizado apenas um tipo de checagem ao
invs das duas, o que pode ser controlado removendo-se alguma camada de pr-composio.

Figura 4.21 Modelo de Projeto do FT de Garantia de Polticas

Figura 4.22 Cdigo do Aspecto pre_weaved_attributechecker
4.4 IAMLIA DL IRAMLWORKS 1RANSVLRSAIS DL
SLGURANA
A famlia de FTs de Segurana desenvolvida no contexto desta tese (Camargo e Masiero,
2005b) visa a facilitar a insero de segurana em aplicaes Web, permitindo que apenas
usurios autorizados acessem o sistema ou parte dele. A arquitetura das aplicaes em que o
FT pode ser acoplado mostrada na Figura 4.23. Nessa arquitetura, as interfaces com o
usurio podem ser implementadas com HTML, JSP ou Servlets; as interfaces que possuem
operaes que sero obrigatoriamente entrecortadas devem ser implementadas com Servlets
ou JSPs. A comunicao com o servidor tambm deve ser feita com Servlets, que instanciam
objetos da aplicao e invocam seus mtodos e operaes.
A famlia de FTs de Segurana possui um FT de Autenticao, um de Controle de
Acesso, um de Registro de Acessos e um de Polticas de Bloqueamento, como pode ser visto
Checker
enabled
setEnabled()
AttributeChecker GetSetChecker
Pre_weaved_Att ri but eChecker
Pre_weaved_GetSetChecker
import persistence.policyEnforcement.*;

public aspect pre_Weaved_AttributeChecker extends AttributeChecker {

public pointcut mainPointcut (Object o) :

XOORelationalMapping.topLevelJoinPointFullConstructor(o);

}

98
na Tabela 4.1. Na Figura 4.24 mostrado o diagrama de caractersticas que representa a linha
de produtos de FTs de segurana (Gomma, 2004). As caractersticas destacadas em cinza
foram implementadas como FTs. O FT de autenticao, que uma caracterstica obrigatria,
exige que o FT de persistncia esteja acoplado ao sistema para que possa funcionar
adequadamente. Isso necessrio porque o FT de Autenticao precisa acessar o banco de
dados para efetuar a validao do nome do usurio e da senha.

Figura 4.23 Arquitetura das Aplicaes em que o FT de Segurana pode ser Aplicado

O FT de Autenticao tem como objetivo permitir que apenas usurios autorizados
possam acessar o sistema. Quando esse FT utilizado, uma interface de gerenciamento de
usurios torna-se disponvel para que o administrador do sistema possa gerenciar os usurios
e suas contas. O funcionamento desse FT ocorre da seguinte forma: quando algum tenta
acessar o sistema, o framework entrecorta a execuo da operao que deve ser protegida e
exibe uma interface solicitando o nome do usurio e a senha. Em seguida, o framework
realiza a validao dos dados e permite ou no o acesso ao sistema.

Figura 4.24 Diagrama de Caractersticas da Linha de Produtos de FTs de Segurana
Interfaces
Html/JSP/
Servlets
Servlets Aplicao
request
response
Cliente
P8
Servidor
Successive
<<default feature>>
Daily
{mutually exclusive feature}
AccessControl
<<opti onal feat ure>>
AccessLog
<<opti onal feature>>
AuthenticationPolicies
Persistent Operations
<<common feature>>
Authentication
<<common feature>>
mutually includes requires requi res
requires
99
Do ponto de vista do engenheiro de aplicao, o FT de Autenticao possui apenas
interface de entrecorte dinmica, pois esse profissional no tem a responsabilidade de chamar
mtodos e operaes a partir do cdigo-base. Entretanto, do ponto de vista do engenheiro do
framework, tambm h interface de entrecorte esttica. A interface de gerenciamento de
usurios disponibilizada um exemplo desse tipo de interface. Quem decide o momento de
criar, remover ou alterar os usurios do sistema o administrador. Assim como o FT de
Persistncia, no h pontos de juno que podem ser determinados no cdigo-base. A
diferena entre esses FTs que, no caso do FT de Autenticao, a interface com o usurio
tambm disponibilizada, eliminando essa tarefa do engenheiro de aplicao, o que no
ocorre com o FT de Persistncia.
O FT de Autenticao dependente de contexto, isto , ele precisa capturar dados do
cdigo-base para realizar suas responsabilidades. Ele deve ser acoplado a um sistema em um
ponto de juno em que seja possvel capturar os objetos HttpServletRequest e
HttpServletResponse, pois ele utiliza esses objetos para ter acesso sesso do usurio.
O FT de Controle de Acesso tem como objetivo controlar o acesso a determinadas
partes do sistema dependendo do papel que o usurio possui. Quando esse FT utilizado, um
sub-sistema de gerenciamento se torna disponvel para que o administrador possa gerenciar os
papis que os usurios possuem e as operaes do sistema que podem ser executadas por cada
papel. Para que esse FT tenha condies de gerenciar papis, necessrio que o FT de
autenticao j esteja presente no sistema. Esse FT possui interface de entrecorte dinmica e
esttica, sendo que apenas a dinmica tratada durante o processo de reso. Sua interface de
entrecorte esttica introduz mtodos e atributos em classes do FT de Autenticao, mas
nenhuma tarefa precisa ser feita pelo engenheiro de aplicao. Basta que esse FT seja includo
no projeto para que essa interface atue corretamente.
O FT de Registro de Acesso armazena informaes em uma tabela de banco de dados
sobre os usurios que entram e saem do sistema, como, por exemplo: data de entrada, hora de
entrada, data de sada e hora de sada. Esse FT opcional e depende da presena do FT de
autenticao para que possa funcionar adequadamente. A nica interface de entrecorte desse
FT dinmica, pois entrecorta pontos de juno do FT de Autenticao.
O FT de polticas de bloqueamento fornece ao FT de Autenticao duas formas de
controlar o nmero de vezes que um usurio pode errar a senha, sob pena de bloqueamento da
conta. Esse FT possui duas variabilidades: diria e sucessiva. Caso a poltica de bloqueamento
diria seja escolhida, o usurio no pode errar sua senha um nmero estipulado de vezes no
mesmo dia. Caso a sucessiva seja escolhida, o usurio no pode errar sua senha um

100
determinado nmero de vezes consecutivamente. O tempo mximo entre uma tentativa e outra
deve ser estipulado pelo administrador. Esse FT possui apenas interface de entrecorte
dinmica com o FT de Autenticao.
Como mostrado na Tabela 4.1, os FTs de Autenticao e de Controle de Acesso
devem ser diretamente acoplados a uma aplicao, e no a outros FTs. J os FTs de registro
de acesso e de polticas de bloqueamento so caractersticas opcionais do FT de Autenticao
e s podem ser acoplados a esse FT. Embora Access Control seja uma caracterstica opcional,
um FT que deve ser acoplado a uma aplicao e no a outro FT. A escolha dessa
caracterstica automaticamente inclui o FT de Autenticao.
A adio de caractersticas no FT de persistncia foi mostrada aps esse FT ter sido
acoplado a uma aplicao. Nesta seo ser mostrado que o acoplamento das caractersticas
tambm pode ser feito antes que o FT seja acoplado aplicao. Assim, ser mostrado o
acoplamento do FT de Polticas de Bloqueamento com o FT de Autenticao gerando um FT
com os requisitos exigidos. Depois disso a composio com a aplicao pode ser feita.
O projeto do FT de autenticao mostrado na Figura 4.25. Este modelo tambm
mostra as classes criadas durante a etapa de instanciao, que esto destacadas em cinza.
Como esse FT dependente de contexto e foi implementado com trs alternativas de
composio do padro Capturador de Objetos, optou-se por representar cada alternativa em
um diagrama de seqncia. Dessa forma, o engenheiro de aplicao sabe quantas alternativas
de composio esto disponveis e consegue visualizar o comportamento de cada uma. Por
exemplo, o primeiro diagrama de seqncia representa a alternativa WithParameters, como
mostra a nota. Observe-se que na lista de parmetros do mtodo-gabarito
protectedOperation() aparecem dois objetos, um do tipo HttpServletRequest, e
outro do tipo HttpServletResponse. Isso mostra que, para utilizar essa alternativa de
composio, o engenheiro de software deve fornecer um ponto de juno que seja a chamada
ou a execuo de algum mtodo que possua esses dois objetos como parmetros. Como esse
FT dependente de plataforma Web, fcil encontrar mtodos que possuam esses dois
objetos, como por exemplo o doPost() e o doGet() dos servlets. Observe-se tambm
que o mtodo defineRequestAndResponse() utiliza esses dois objetos capturados.
O segundo diagrama de seqncia representa a alternativa de composio Target.
Essa alternativa deve ser usada quando o ponto de juno a ser fornecido consiste em uma
chamada ou execuo de mtodo cujo objeto alvo possua os dois objetos requeridos pelo FT.
Observe que a lista de parmetros do mtodo-gabarito possui dois pontos (..), indicando que
no importa se o mtodo que ser fornecido como ponto de juno possui ou no parmetros.
101
Isso acontece porque o FT ir utilizar o objeto alvo da chamada, que o objeto app. Note-se
que esse objeto utilizado pelo framework no mtodo defineRequestAndResponse().

Figura 4.25 Modelo de Projeto do FT de Autenticao
Authentication
<ApplicationClass.protectedOperation(..)>

Context : ApplicationClass : Authent icati on
protectedOperation(HttpServletRequest r1, HttpServletResponse r2)
[ test = true] do_prot ectedOperation(..)
defineRequestAndResponse(r1,r2 )
test := hasAnySubjectAuthenticated( )
[test = false] redi rect ToAuthenticat ionInt erface( )
Wit hParameters
Target (call or
execution)
app : ApplicationClass : Authentication
protectedOperation(..)
[test = true] do_protectedOperation(..)
defineRequestAndResponse(app)
[test = false] redirectToAuthenticationInterface( )
app : ApplicationClass : Authentication
This (call)
protectedOperation(..)
[test = true] do_protectedOperation(..)
defineRequestAndResponse(con)
[test = false] redirectToAuthenticationInterface( )
Role
ID
description
MyAuthentication
getNameOfLoginInterfaceWithPackage()
MysrvLogin
getNameOfValidationClassWithPackage()
srvMyValidation
getNameOfMainInterface()
srvLogin
<<hook>> get NameOfValidationClassWithPack age()
srvAdministrator
links : Vector
<<hook>> defineLinks()
<<hook>> getNewLinkFactory()
Link
linkDescription
fileName
Subject Factory
<<hook>> createNewSubjectInstance() : Subject
LinkFactory
getNewLi nkInstance()
ValidationClass
isUserNameValidated(subject) : Boolean
isPasswordValidat ed(subject) : Boolean
do_isPasswordVal idated()
HttpSession
<<utility>>
srvValidation
showNotPermitedUserInterface()
showPasswordNotValidatedInterface()
<<hook>> getNameOfMainInterface() : String
<<invokes>>
Subject
ID
name
userName
password
<<instantiates>>
ApplicationClass
protectedOperation()
do_protectedOperation()
Authenti cation
myResponse
myRequest
defineRequestAndResponse()
hasAnySubjectAuthenticated() : Boolean
redirectToAuthenticationInterface()
getResponse()
getObject() : Vector
<<hook>> getNameOfLoginInterfaceWithPackage() : String
<<redi rect >>

102
A terceira alternativa de composio implementada por este FT a This. Nesse caso, o
objeto capturado pelo FT ser o objeto this e no o target, como no diagrama de
seqncia anterior.
Na Figura 4.26 mostrado o modelo de projeto do FT de Polticas de Bloqueamento,
que uma caracterstica opcional do FT de Autenticao. Como esse FT uma variabilidade
do FT de Autenticao, ele foi implementado apenas com a alternativa de composio Args,
como pode ser visto no diagrama de seqncia. Isso foi feito j com vistas ao acoplamento
com o FT de Autenticao. O diagrama de seqncia tambm mostra que o ponto de juno
que deve se fornecido deve se a chamada ou execuo de um mtodo que possua como
parmetro um objeto do tipo Subject, que um tipo pr-definido do FT de Autenticao.

Figura 4.26 Modelo de Projeto do FT de Polticas de Autenticao
LockingPolicies
<PasswordValidation.validatePassword()>
Context : PasswordValidation : LockingPolicyVariabilities
validatePassword(Subject s)
isValidated : =_do_val idatePassword( )
[isValidated = false] getLockingPol icy()
analyseLocking(s)
Args
[isVal idated = t rue]
srvSuspendedSubject
getNewSubjectFactory() : Subject Fact oryI
srvUnblockSubject
getNewSubjectFactory() : SubjectFactoryI
srvNumberOfWrongAttemptsController
myFi le : File
srvWri teWrongAtt emptsNumber FileManager
getContent()
writeFi le()
srvTimeBetweenWrongAttemptsController
getNewSuccessiveFactory() : SuccessiveFactoryI
srvWriteTimeBetweenWrongAttempts
getNewSuccessiveFactory() : SuccessiveFactoryI
Successive
maxTimeBetweenWrongAttempts
analyseLocking() : Boolean
Daily
getNewSubj ect Factory() : SubjectFactoryI
WrongAttemptData
numberOfWrongAttemps
timeOfFirstWrongAttempt
<<invoke>>
<<invoke>>
LockingPolicyVariabilities
links : Vector
defineGeneralLinks() : Vector
showYouAreBlockedInterface()
PasswordValidation
validatePassword()
_do_validatePassword()
Subject
ID
name
userName
password
findAllLockedSubjects()
getLockedSubjects()
isLocked() : Boolean
Role
ID
description
103
Na Figura 4.27 mostrada a composio entre o FT de Autenticao e o de Polticas
de Bloqueamento. Esse ltimo no est sendo mostrado completamente porque pode ser visto
na Figura 4.26. O relacionamento de ligao (bind) entre eles destaca o ponto de juno do FT
de Autenticao que ser afetado pelo FT de Polticas, que o mtodo
isPasswordValidated() da classe Validation. A etiqueta ThemeName utilizada para
nomear o tema resultante.

Figura 4.27 Composio entre o FT de Polticas de Bloqueamento e o FT de Autenticao
As classes Subject e Role se repetem em ambos os FTs, caracterizando o conceito de
compartilhamento de conceitos da abordagem Tema. O FT resultante desta composio,
mostrado parcialmente na parte superior da Figura 4.28, contm todas as classes do FT de
autenticao e mais todas as classes do FT de polticas de bloqueamento. As classes que se
repetem em ambos FTs (Subject e Role) aparecero apenas uma vez no FT resultante,
porm com todos os atributos e mtodos oriundos dos dois FTs. Por motivos de simplicidade
apenas as classes mais importantes esto sendo exibidas, porm todas as outras tambm esto
Authentication

LockingPolicies
<PasswordValidation.validatePassword()>

ThemeName(Authentication)
bind [ <ValidationClass.isPasswordValidated(..) >]

srvSuspendedSubj ect
getNewSubj ectFactory() : Subj ectFactoryI
Subject
findAl l LockedSubj ects()
getLockedSubj ects()
i sLocked() : Bool ean
srvUnblockSubj ect
getNewSubj ectFactory() : Subj ectFactoryI
srvNumberOfWrongAttemptsControll er
myFi l e : Fi l e
srvWri teWrongAttemptsNumber
Fi l eManager
getContent()
wri teFi l e()
srvTi meBetweenWrongAttemptsControl l er
getNewSuccessi veFactory() : Su ccessi veFactoryI
srvWri teTi meBetweenWrongAttempts
getNewSuccessi veFactory() : Successi veFactoryI
Successi ve
maxTimeBetweenWrongAttempts
anal yseLocki ng() : Bool ean
defi neSpeci fi cLi nks()
getNewSubj ectFactory() : SubjectFactoryI
Dai l y
getNewSubjectFactory() : Subj ectFactoryI
Rol e
getDescri pti on()
getID()
showAvai l abl eOperati ons()
catchOperati on()
<<invoke>>
<<i nvoke>>
WrongAttempt Data
numberOfWrongAtt emps
ti meOfFi rstWrongAttempt
Locki ngPol i cyVari abi l i ti es
maxNumberOfWrongAttempts
subj ectAndWrongAttempts
showYouAreBl ockedInterface()
Locki ngPol i cyHooksHandler
<<hook>> getChosenLocki ngPol i cyInstance() : Locki ngPol icyVari abi l i tyI
getLocki ngPol i cy() : Locki ngPol i cyVari abi li tyI
getObject()
PasswordVal i dati on
val idatePassword()
_do_val i datePassword()
Wi thParamet ers
getObj ect()
<<hook>> get IndexOf Args()

104
presentes. Observe-se que a classe Subject possui todos os atributos oriundos do FT de
Autenticao e mais todos os mtodos oriundos do FT de polticas de bloqueamento.

Figura 4.28 Composio com a Aplicao
Na Figura 4.28 tambm mostrada a composio entre o FT de autenticao
resultante e uma aplicao hipottica. O relacionamento de ligao representa que quando o
mtodo jspService() da classe de interface index.jsp for executado o comportamento
transversal encapsulado pelo framework ser executado.
Todos os FTs que manipulam dados persistentes com um banco de dados, assim como
o FT de Autenticao, so dependentes do FT de Persistncia. No diagrama de caractersticas
ilustrado na Figura 4.24 pode-se notar que o FT de Persistncia uma caracterstica
obrigatria quando o FT de Autenticao utilizado. Dessa forma, uma situao que pode
ocorrer a necessidade acoplar o FT de Autenticao em um cdigo-base que j possua
Authentication

CDStore
bind [<Index_jsp.jspService()>]
index_jsp
jspService()
srvColorRegister
srvClientRegister
srvCDRegister
Client Color CD
<<invokes>>
<<invokes>>
<<invokes>>
srvLogin
<<hook>> get NameOf Validat ionClassWit hPackage()
SubjectFactory
<<hook>> createNewSubjectInstance() : Subject
HttpSession
<<utility>>
srvValidation
showNotPermitedUserInterface()
showPasswordNotValidatedInterface()
<<hook>> getNameOfMainInterface() : St ri ng
<<invokes>>
Role
ID
description
Subject
ID
name
userName
password
findAllLockedSubjects()
getLockedSubjects()
isLocked() : Boolean
ApplicationCl ass
protectedOperation()
do_protectedOperation()
Authentication
myResponse
myRequest
defineRequestAndResponse()
hasAnySubjectAuthenticated() : Boolean
redirectToAuthenticationInterface()
getResponse()
getObject() : Vector
<<hook>> getNameOfLoginInterfaceWithPackage() : St ri ng
<<redirect>>
ValidationClass
isUserNameValidated(subject) : Boolean
isPasswordValidated(subject) : Boolean
do_isPasswordValidated()
105
persistncia implementada com alguma outra tcnica, seja de forma convencional ou com o
apoio de algum framework de persistncia, como, por exemplo, o Hibernate (Hibernate,
2006).
Quando isso ocorre, uma opo eliminar todo o cdigo de persistncia que j est
implementado e fazer com que a aplicao utilize a persistncia disponibilizada pelo FT. A
vantagem dessa opo que o interesse de persistncia dentro da aplicao torna-se bem
modularizado e que a arquitetura da aplicao torna-se mais clara. Entretanto, dependendo do
tamanho da aplicao e do nvel de entrelaamento da persistncia que j est implementada,
o esforo para isso pode ser bastante significativo, podendo inviabilizar essa deciso. A outra
opo consiste em acoplar o FT na aplicao juntamente com o FT de Persistncia, fazendo
com que a aplicao possua o interesse de persistncia implementado de duas formas
diferentes. Assim, a aplicao continua utilizando a persistncia que j estava implementada e
o FT de Autenticao utiliza o FT de Persistncia. A desvantagem dessa opo que o
interesse de persistncia estar implementado de duas formas dentro da mesma aplicao,
tornando o projeto confuso. Porm, uma opo interessante quando os prazos esto
apertados porque no sero necessrias modificaes no cdigo-base, agilizando o processo.
4.S IAMLIA DL IRAMLWORKS 1RANSVLRSAIS DL RLGRAS
DL NLGCIO
Os FTs de regras de negcio so exemplos do uso de aspectos para encapsular requisitos
funcionais (Suve et al., 2005; Cibrn et al., 2003; Cibrn et al., 2006) e se assemelham
idia de implementar caractersticas transversais funcionais de um domnio com aspectos
(Mezini e Ostermann, 2004; Apel et al., 2006). Esses FTs foram criados durante o
desenvolvimento de um sistema de reservas de uma rede de hotis, que ser exemplificado em
detalhes no Captulo 7.
Como o FT de Clculo Baseado em Tabela j foi discutido na Seo 3.3.1, no ser
discutido novamente neste captulo. O FT de Reajuste de Valor ser exemplificado com mais
detalhes no Captulo 7, em que um exemplo de uso do ProFT/PU mostrado.
Os FTs apresentados e discutidos nesta seo no procuram cobrir todas as funcionalidades
dos interesses por ele encapsulados. No caso do FT de persistncia, gerenciamento de
transaes, tratamento de objetos sujos, acesso a dados sob demanda, conexes com banco de
dados orientados a objetos, e outros detalhes poderiam ter sido implementados na arquitetura.

106
O mesmo pode ser dito com relao ao FT de Segurana. Entretanto, o objetivo foi averiguar
a viabilidade e a possibilidade de implementar linhas de produtos de FTs em que
determinadas caractersticas tambm so FTs. Assim, antes que o FT seja composto com uma
aplicao, suas caractersticas so escolhidas e acopladas para prover os requisitos exigidos,
fazendo com que apenas as variabilidades utilizadas estejam presentes na arquitetura do FT.
O nvel de maturidade dos FTs tambm um detalhe importante a ser ressaltado. O FT
com o maior nvel de maturidade o de persistncia, pois j foi utilizado no desenvolvimento
de seis sistemas acadmicos, como pode ser visto na Tabela 5.10. Assim, grande parte de sua
arquitetura j foi testada. Entretanto, o mesmo no ocorre com o FT de Segurana, que foi
utilizado no desenvolvimento de apenas trs sistemas. Somente com o reso dessa famlia no
desenvolvimento de outros sistemas que novas variabilidades podero ser identificadas.
Quando vrios aspectos so utilizados durante o desenvolvimento de uma aplicao,
um ponto importante a precedncia de atuao entre eles. Os FTs apresentados
anteriormente possuem mecanismos de precedncia j implementados em sua arquitetura para
que os problemas de precedncia seja minimizados. Isso possvel porque j se conhece de
antemo os FTs que podem ser utilizados no projeto. Quando novos FTs so desenvolvidos,
deve-se tambm cuidar para que esses mecanismos de precedncia sejam atualizados.
Entretanto, mesmo com os mecanismos j implementados, interessante que o desenvolvedor
tenha conscincia dos pontos de juno que so afetados por dois ou mais aspectos.
A maior parte dos trabalhos encontrados na literatura que tratam de frameworks
orientados a aspectos de um nico interesse tem enfoque em detalhes arquiteturais e de
implementao. Alguns mais recentes j se preocupam com o agrupamento de vrios desses
frameworks em algum repositrio que facilite o reso, como, por exemplo, bibliotecas de
aspectos reusveis. Porm, no foram encontrados trabalhos na literatura especializada que
mostrassem processos de desenvolvimentos apoiados por aspectos reusveis.

Captulo 5
. t vao. ae Ca.o

S.J CONSIDLRALS INICIAIS
Neste captulo so apresentados estudos que foram conduzidos com o objetivo de testar,
comparar ou, simplesmente, averiguar determinadas particularidades dos FTs desenvolvidos.
Foram conduzidos vrios estudos informais com o objetivo de testar os FTs e identificar
novas funcionalidades. Tambm foi conduzido um estudo em que o objetivo foi averiguar a
dificuldade de acoplamento de um FT em uma aplicao. Um outro estudo, mais formal, teve
o objetivo de comparar o tempo de composio de um FT de persistncia com o tempo de
composio de um framework orientado a objetos de persistncia.
Na Seo 5.2, um estudo que comparou o tempo de composio de dois frameworks
de persistncia um orientado a objetos e outro orientado a aspectos apresentado. Na
Seo 5.3, um outro estudo, menos formal, cujo objetivo foi averiguar a dificuldade de
encontrar um ponto de juno adequado em um cdigo-base desestruturado mostrado. Na
Seo 5.4, outros estudos informais que foram conduzidos como parte desta pesquisa so
discutidos.
S.2 - UM LS1UDO COMPARA1IVO DO 1LMPO DL
COMPOSIO LN1RL I1S
Nesta seo apresentado um estudo quantitativo que comparou o tempo de composio de
um framework OO de persistencia com o FT de persistencia desenvolvido no contexto desta
tese (Camargo et al., 2006). Vrios trabalhos relatam que o uso da POA na implementao de
frameworks de um nico interesse resulta em benefcios de manuteno, reso e legibilidade
Captulo 5 Estudos de caso

108
de cdigo. Em particular, o interesse de persistncia tem sido bastante pesquisado nesse
sentido (Soares et al., 2002; Couto et al., 2005; Rashid and Chitchyan, 2003). Contudo, no
foram encontrados trabalhos cujo foco fosse averiguar se a POA tambm afeta o tempo de
composio desses frameworks com o cdigo-base. Esse um fator importante porque a
adoo de uma nova tecnologia, por exemplo, um framework, pode depender, alm de outros
fatores, da produtividade e eficincia que essa nova tcnica traz para a equipe de
desenvolvimento.
O estudo segue a estrutura proposta por Wohlin (2000) e foi conduzido no primeiro
semestre de 2006. Para a realizao do estudo foram utilizadas duas verses do FT de
persistncia: uma orientada a objetos e uma orientada a aspectos. A verso orientada a objetos
foi desenvolvida a partir da verso orientada a aspectos, e manteve a arquitetura e a
funcionalidade dessa verso, sendo modificada apenas a tcnica utilizada para a composio
com o cdigo-base.
Como o FT de persistncia foi desenvolvido com a preocupao de utilizar aspectos
apenas onde fosse necessrio, a criao de uma verso OO foi facilitada. Por exemplo, no FT
de persistncia, uma das tarefas da etapa de composio fazer com que as classes
persistentes da aplicao estendam a interface PersistentRoot, o que feito com
declaraes inter-tipo da linguagem AspectJ. No caso do framework de persistncia OO, as
classes persistentes da aplicao tambm devem estender a mesma interface, porm isso
feito introduzindo-se declaraes extends PersistentRoot em cada uma das classes.
Outro exemplo a composio da conexo, que no FT feita concretizando-se dois conjuntos
de juno (pointcuts) por meio da criao de um aspecto concreto. J no framework OO, essa
composio feita por meio da invocao de mtodos para abrir e fechar a conexo em vrios
pontos do cdigo.
Como comentado anteriormente, o processo de reso de um framework que trata de
um nico interesse feito em duas etapas: instanciao e composio. A etapa de instanciao
para as duas verses do frameworks de persistncia idntica, e consiste em escolher o tipo
de conexo com o banco de dados. Como o objetivo do estudo foi comparar apenas a etapa de
composio, os participantes do estudo receberam os frameworks com a instanciao j
realizada, bastando apenas realizar a etapa de composio do framework com o cdigo-base.
O framework de persistncia utilizado no estudo, independentemente da verso (OO
ou OA), possui duas partes distintas. A primeira corresponde ao que chamado de operaes
persistentes: um conjunto de operaes bsicas de persistncia que devem ser adicionadas s
classes persistentes da aplicao. A segunda parte corresponde conexo com o banco de
109
dados, a qual consiste em determinar pontos da aplicao em que a conexo deve ser aberta e
fechada. A etapa de composio do FT foi definida em trs passos para a conduo do
experimento, sendo que os dois primeiros correspondem ao acoplamento dessas duas partes
com o cdigo base, e o ltimo aos testes de acoplamento. Embora essas duas partes formem a
persistncia como um todo, esto sendo tratadas de forma separada porque a composio com
o cdigo-base utiliza tcnicas diferentes de programao, tanto na verso OO quanto na OA.
Coletando separadamente os dados foi possvel averiguar qual das partes tem mais impacto no
tempo de composio total.
Os passos da etapa de composio foram definidos como: 1) Acoplar Comportamento
de Persistncia; 2) Acoplar Conexo e 3) Testar Acoplamento. Esses so os passos realizados
pelos participantes do estudo para a coleta de dados. Para os dois primeiros passos, os
participantes registraram o tempo de realizao do passo, a quantidade de linhas de cdigo
escritas, a quantidade de locais modificados e a quantidade de unidades criadas, isto ,
classes, pacotes e aspectos. Para o ltimo passo apenas o tempo foi registrado. Na Tabela 5.1
so mostrados os dados que foram coletados e a respectiva sigla de cada um.
O primeiro passo da etapa de composio do FT consiste em criar um aspecto que
estende o aspecto abstrato PersistentEntities do framework e que declare, por meio de
declaraes inter-tipo, todas as classes persistentes da aplicao que devem implementar a
interface PersistentRoot, como mostrado na Figura 5.1.

Tabela 5.1 Significado das Siglas dos Dados Coletados
Legenda dos Dados Coletados
Dados para Coletar Siglas
Tempo de Acoplamento do Comportamento de Persistncia (Passo 1) TACP
Tempo de Acoplamento da Conexo (Passo 2) TAC
Tempo de Teste do Acoplamento (Passo 3) TTeste
Quantidade de Linhas de Cdigo Escritas LC
Quantidade de Unidades (classes, aspectos, pacotes) Criadas UC
Nmero de Locais modificados LM

Figura 5.1 Acoplamento do Comportamento de Persistncia AO
J no caso do framework OO de persistncia, a realizao do primeiro passo consiste
em inserir a declarao extends PersistentRoot e a declarao de importao
import persistence.PersistentRoot, em cada classe persistente de aplicao,
assim como est sendo mostrado na Figura 5.2.
O segundo passo da etapa de composio consiste em estabelecer os locais do cdigo
onde a conexo deve ser aberta e fechada. Geralmente isso deve ser feito em programas
declare parents : Departamento implements PersistentRoot;
declare parents : Endereco implements PersistentRoot;
declare parents: Funcionario implements PersistentRoot; }

110
(cdigo-cliente) que usam objetos das classes persistentes definidas no passo anterior. No
caso do FT, um aspecto concreto deve ser criado para estender o aspecto abstrato
ConnectionComposition do FT, como est sendo mostrado na Figura 5.3. O aspecto
abstrato ConnectionComposition possui dois conjuntos de juno abstratos:
openConnection() e closeConnection() que devem ser concretizados. O conjunto de
juno openConnection() deve ser concretizado de forma a entrecortar pontos da
aplicao em que a conexo deve ser aberta, e o closeConnection()deve entrecortar
pontos em que a conexo deve ser fechada. Alm disso, tambm deve-se implementar o
mtodo-gancho getNameOfConnectionVariabilitiesClass(). Esse mtodo deve ser
implementado de forma a retornar o nome da classe que foi criada na etapa de instanciao.
Como a instanciao j havia sido realizada, o nome dessa classe tambm foi informado aos
participantes.

Figura 5.2 Acoplamento do Comportamento de Persistncia OO
Para o framework OO, a realizao do segundo passo consiste em instanciar um objeto
da classe MyConnectionVariabilities e chamar o mtodo ConnectDB()em todos os
pontos do cdigo-base onde a conexo deve ser aberta e fechada. O estabelecimento da
conexo deve ser feito logo no incio dos programas e o encerramento deve ser feito no final.
Na Figura 5.4 so mostradas em negrito as linhas de cdigo que devem ser inseridas para que
a composio possa ser realizada com um programa.

Figura 5.3 Acoplamento da Conexo AO

A etapa de teste foi idntica para ambos os frameworks. Consistia em executar
determinados programas e verificar se a sada correspondia sada esperada. Por exemplo,
uma das aplicaes usadas no estudo possui um programa chamado RegisterOfEvents,
cujo objetivo armazenar em vrias tabelas do banco de dados eventos que os funcionrios
podem gerar durante o ms, por exemplo faltas, horas extras e atrasos. Se a execuo desse
programa no armazenar todos os dados esperados, a etapa de composio no pode ser
considerada concluda e o erro deve ser rastreado e corrigido. Optou-se por no fornecer
public aspect myConnectionCompositionRules extends ConnectionComposition {

pointcut openConnection(): execution (public static void SomeClass.main(..));
pointcut closeConnection(): execution(public static void SomeClass.main(..));

return "instantiation.myConnectionVariabilities";
}}

import persistence.PersistentRoot;
public class [ClassName] extends PersistentRoot { }
111
interfaces grficas para as aplicaes para que o tempo dos testes no fosse influenciado. O
fornecimento dos programas fez com que todos realizassem os mesmos testes em tempos
bastante prximos.

Figura 5.4 Acoplamento da Conexo - OO
S.2.J - Definio do estudo
O objetivo foi Analisar o tempo de composio de um FT de persistncia com uma aplicao
e de um FOO de persistncia com uma aplicao para o propsito de avaliao com respeito
eficincia do ponto de vista de desenvolvedores de software no contexto de estudantes de
ps-graduao em Cincias da Computao.
S.2.2 - Planejamento do estudo
a) Seleo do contexto. O estudo foi realizado com estudantes de ps-graduao em Cincia
da Computao, no contexto da disciplina de Tpicos Avanados em Engenharia de Software,
utilizando aplicaes de domnio genrico (Loja de CDs e Oficina Eletrnica).

b) Formulao de hipteses. Foram elaborados trs tipos de hipteses para o estudo: as
hipteses para o efeito do uso do Framework de Persistncia no resultado podem ser vistas na
Tabela 5.2; as hipteses para o efeito do uso das Aplicaes no Resultado encontram-se na
Tabela 5.3, e as hipteses para o efeito do grupo ou efeito da Interao Aplicao X
Framework esto na Tabela 5.4.
c) Seleo de variveis. As variveis independentes so todas aquelas que so manipuladas e
controladas durante o estudo. No estudo realizado essas variveis so os Frameworks de
persistncia (OO e OA) e as aplicaes (Loja de CDs e de Oficina Eletrnica).
As variveis dependentes so aquelas que esto sob anlise. Devem-se observar suas
variaes com base nas mudanas feitas nas variveis independentes. No caso do estudo
realizado a varivel dependente o tempo de composio.
Tabela 5.2 Hipteses para o Efeito do Framework de Persistncia
H
0
: No h diferena entre desenvolvedores utilizando Framework de Persistncia OA e
desenvolvedores utilizando Framework de Persistncia OO com respeito eficincia individual.
Ha: H diferena entre desenvolvedores utilizando Framework de Persistncia OA e desenvolvedores
utilizando Framework de Persistncia OO com respeito eficincia individual.

public class admissaoDeAssalariado {
public static void main(String[] args) {
MyConnectionVariabilities con = new MyConnectionVariabilities();
con.ConnectDB();
// Todo o comportamento do programa
con.DisconnectDB();
}}


112
Tabela 5.3 Hipteses para o Efeito do Uso das Aplicaes no Resultado
H
0
: No h diferena entre desenvolvedores fazendo o acoplamento na Aplicao Loja de CDs e
desenvolvedores fazendo o acoplamento na Aplicao Oficina Eletrnica com respeito eficincia
individual.
Ha: H diferena entre desenvolvedores fazendo o acoplamento na Aplicao Loja de CDs e
desenvolvedores fazendo o acoplamento na Aplicao Oficina Eletrnica com respeito eficincia
individual.

Tabela 5.4 Hipteses para o Efeito do Grupo ou Efeito da Interao
H
0
: No h diferena entre o grupo que fez o acoplamento de um FOA com uma aplicao e o grupo
que fez o acoplamento de um FOO em relao a eficincia.
Ha: H diferena entre o grupo que fez o acoplamento de um FOA com uma aplicao e o grupo que fez
o acoplamento de um FOO em relao a eficincia.

d) Seleo dos participantes. Os participantes do estudo foram selecionados por meio de
amostragem no-probabilstica por convenincia. Eram alunos de ps-graduao da disciplina
de Tpicos Avanados em Engenharia de Software, ministrada no ICMC/USP.

e) Projeto do estudo realizado. O estudo foi planejado em bloco e balanceado para assegurar
que os tratamentos tivessem igual nmero de participantes e para possibilitar a comparao
dos efeitos das variveis independentes, como pode ser visto na Figura 5.5. Na segunda fase
do estudo, os 4 participantes mais experientes em OO e OA e nas linguagens Java e AspectJ
executaram novamente as etapas do projeto experimental anterior, sendo invertidas as
combinaes dos frameworks com as aplicaes (Figura 5.5).
f) Tipo de projeto: dois fatores com dois tratamentos (2*2 fatorial)
A distribuio dos participantes nos grupos foi realizada visando a colocar a mesma
quantidade de participantes experientes nos dois grupos. A experincia dos participantes foi
avaliada pelo questionrio de caracterizao dos participantes, que pode ser encontrado no
anexo 3 desta tese. O grfico mostrado na Figura 5.6 (a) mostra a experincia dos
participantes em Java, AspectJ e POA, e o grfico (b) mostra a experincia com programao
em Java e AspectJ. Os participantes P1, P2, P7 e P8 foram considerados experientes em POA.

Aplicaes

Loja de CDs Oficina Eletrnica
Treinamento: exemplo de Composio do Framework de Persistncia OO e OA em
uma terceira aplicao.
Framework OO Grupo 1 Grupo 2
1.
Fase
Framework OA Grupo 2 Grupo 1
Framework OO P4, P12 P1, P11
Framework de
Persistncia
2
Fase Framework OA P1, P11 P4, P12
Figura 5.5 Projeto Experimental
g) Instrumentao. Os participantes deveriam contabilizar o tempo gasto para realizar a
composio utilizando cada um dos frameworks.
113
Os documentos utilizados no estudo foram: formulrio de caracterizao dos
participantes, para obteno da experincia profissional e nos assuntos relacionados
diretamente ao estudo; Formulrio de registro, para preenchimento de todas as informaes
durante a execuo do estudo; Roteiro de execuo, roteiro com todos os passos a serem
seguidos para execuo do estudo.

Figura 5.6 (a) Experincia dos participantes em POA, Java e AspectJ; (b) Experincia dos participantes
nas linguagens JAVA e AspectJ (linhas de cdigo)

Os frameworks utilizados foram um de persistncia orientado a objetos e um de
persistncia orientado a aspectos. As duas aplicaes utilizadas foram um sistema para loja de
CDs e um sistema para Oficina Eletrnica. A aplicao de loja de CDs possui 6 classes e 13
programas. O sistema de oficina eletrnica possui 7 classes e 12 programas. As aplicaes
possuem complexidade similar e aproximadamente o mesmo nmero de linhas de cdigo.
Assim como os frameworks, essas aplicaes foram desenvolvidas no meio acadmico.
Foi realizado um pequeno treinamento visando a uniformizar o conhecimento sobre
programao orientada a aspectos e de Frameworks (OO e OA). Tambm fez parte do
treinamento a utilizao de uma terceira aplicao, com a qual deveriam ser feitos os
acoplamentos utilizando os frameworks OO e OA e todos os formulrios que seriam
utilizados no estudo posteriormente, para que o aprendizado sobre como fazer uma
composio utilizando os frameworks e como preencher os formulrios no interferisse no
tempo de acoplamento durante o estudo.
O objetivo da primeira fase foi realizar uma avaliao pura do tempo de composio e
por isso, os pontos de acoplamento do cdigo-base foram informados. J na segunda fase, o
objetivo foi avaliar se a existncia de uma nova dificuldade tambm interfere nos resultados,
no informando aos participantes os pontos de acoplamento.
(a) (b)
Experincia em Java, POA e AspectJ
3,00
2,33 2,33
1,00
1,67
0,33
2,67
3,00
2,33
1,33
1,00
0,67
0,00
0,50
1,00
1,50
2,00
2,50
3,00
3,50
4,00
P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12
E
s
c
a
l
a

d
e

e
x
p
e
r
i
n
c
i
a
Experincia em programao utilizando
Java e AspectJ
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
P
1
P
2
P
3
P
4
P
5
P
6
P
7
P
8
P
9
P
1
0
P
1
1
P
1
2
L
i
n
h
a
s

d
e

c
d
i
g
o
Java
AspectJ

114
S.2.3 - Lxecuo.
Os participantes executaram as atividades planejadas seguindo o projeto experimental.
Primeiro treinaram a composio de um framework de persistncia OO e depois de um FT em
uma aplicao desenvolvida para exemplo.
Na primeira etapa da execuo, o Grupo 1 utilizou o Framework de Persistncia OO
com a aplicao Loja de CDs, enquanto que o Grupo 2 utilizou o mesmo Framework com a
aplicao Oficina Eletrnica. Na segunda etapa, os grupos utilizaram o Framework de
Persistncia OA, com as aplicaes trocadas: o grupo 1 utilizou a aplicao Oficina Eletrnica
e o Grupo 2 utilizou a aplicao Loja de CDs.
S.2.4 Dados Coletados
Nas Tabelas 5.5 e 5.6 so mostrados os dados da primeira fase do estudo, em que havia tanto
participantes experientes quanto novatos, e na Tabela 5.7, so mostrados os dados da segunda
fase, em que havia apenas participantes experientes. Os significados das siglas dos dados
coletados podem ser visto na Tabela 5.1.
Tabela 5.5 Primeira Etapa da Primeira Fase Composio com o Framework Orientado a Objetos
Primeira Etapa: Composio com Framework Orientado a Objetos de Persistncia
Aplicao Loja de CDs Grupo 1 Aplicao Abaco Grupo 2
P1 P2 P3 P4 P5 P6 mdia P7 P8 P9 P10 P11 P12 mdia
Dados
1- TACP 01:55 10:00 02:11 02:07 01:58 04:00 03:42 05:00 01:58 01:40 03:05 04:00 06:00 03:37
1.1 - LC 10 10 10 10 10 10 16 16 16 16 16 16
1.2 - UC 0 0 0 0 0 0 0 0 0 0 0 0
1.3 - LM 5 5 5 5 5 5 8 8 8 8 8 8
2- TAC 07:45 05:00 05:14 07:50 05:17 15:00 07:41 06:00 04:00 05:51 08:10 05:30 08:00 06:15
2.1 - LC 48 48 48 48 48 48 44 44 44 44 44 44
2.2 - UC 0 0 0 0 0 0 0 0 0 0 0 0
2.3 - LM 12 12 12 12 12 12 11 11 11 11 11 11
3-TTeste 09:20 06:00 03:26 04:04 03:50 05:00 05:17 08:00 00:56 07:09 06:36 06:35 12:00 06:53
Soma
dos
Tempos 19:00 21:00 10:51 14:01 15:57 24:00 16:40 19:00 06:54 14:40 17:51 16:05 26:00 16:45

Os dados foram coletados separadamente para cada passo da etapa de composio do
framework, isto , foram coletados tempo, nmero de linhas de cdigo escritas, nmero de
locais modificados e nmero de unidades criadas para cada um dos trs passos do processo de
composio, a menos do passo de teste, em que foi contabilizado apenas o tempo. Os dados
mostrados nas Tabelas 5.5, 5.6 e 5.7 esto agrupados pelos trs passos da composio. No
primeiro passo, representado pelo dado 1 - TACP (veja Tabela 5.1), os dados 1.1 LC,
1.2 UC e 1.3 LM, que se encontram logo abaixo desse dado e que esto numerados
como subsees, representam os dados coletados durante a realizao desse primeiro passo. O
115
mesmo ocorre com o segundo passo Acoplar Conexo, representado pelo dado 2 TAC.
A letra T significa tempo.
Tabela 5.6 Segunda Etapa da Primeira Fase Composio com o FT de Persistncia
Segunda Etapa: Composio com FT de Persistncia
Aplicao Abaco Grupo 1 Aplicao Loja de CDs Grupo 2
P1 P2 P3 P4 P5 P6 mdia P7 P8 P9 P10 P11 P12 mdia
Dados
1- TACP 05:45 04:00 03:10 03:00 03:10 02:02 03:31 04:00 02:22 03:33 02:58 03:12 10:00 04:21
1.1-LC 13 13 10 13 12 12 10 9 8 9 9 8
1.2-UC 2 2 2 2 2 2 2 2 2 2 2 2
1.3- LM 0 0 1 0 0 0 0 0 0 0 0 0
2- TAC 02:30 01:00 03:35 01:54 02:30 04:00 02:35 02:00 00:42 03:40 02:57 02:32 03:00 02:29
2.1 - LC 10 12 8 12 10 7 10 8 9 12 10 7
2.2 UC 1 1 1 1 1 1 1 1 1 1 1 1
2.3 LM 0 0 1 0 0 0 0 0 0 0 0 0
3-TTeste 08:50 07:00 04:30 07:41 03:56 07:00 06:29 06:00 00:40 05:55 05:30 03:55 03:00 04:10
Soma
dos
tempos 17:05 12:00 11:15 12:35 09:36 13:02 12:35 12:00 03:44 13:08 11:25 09:39 16:00 10:59

A coluna mdia mostra a mdia de tempo que os participantes gastaram na
realizao de cada um dos trs passos e a ltima linha mostra a soma dos tempos de cada
participante e tambm a soma dessas mdias, o que representa o tempo mdio de composio
do framework com a aplicao.
Tabela 5.7 Primeira e Segunda Etapas da Segunda Fase do Estudo
Primeira Etapa Framework Orientado a Objetos Segunda Etapa Framework Transversal
Abaco Grupo1 Loja de CDs Grupo 2 Loja de CDs Grupo 1 Abaco Grupo 2
P1 P2 mdia P7 P8 Mdia P1 P2 Media P7 P8 Mdia
Dado

1- TACP 07:42 07:00 07:21 06:35 03:10 04:53

03:20 03:00 03:10 04:00 04:25 04:13
1.2-LC 16 16 10 10

10 11 9 14
1.3-UC 0 0 2 0

1 1 1 1
1.4- LM 8 8 5 5

0 0 0 0
2-TAC 06:30 07:00 06:45 06:15 06:24 06:19

03:15 02:00 02:38 05:00 00:45 02:53
2.1 - LC 44 44 36 48

12 12 9 9
2.2 UC 0 0 0 0

1 1 1 1
2.3 LM 11 11 12 12

0 0 0 0
Teste 06:05 07:00 06:32 05:00 04:25 04:43

04:18 07:00 05:39 04:00 04:10 04:05
Soma
dos
Tempos 20:17 21:00 20:39 17:50 13:59 15:54

10:53 12:00 11:27 13:00 09:20 11:10

Note-se na Tabela 5.5 que a mdia de tempo de composio do FOO com a aplicao
de loja de CDs (16:40) foi muito similar mdia de tempo da composio desse mesmo
framework com a aplicao Abaco (16:45), o que evidencia que as aplicaes so similares
em tamanho e funcionalidades. Mesmo no caso do FT, essa mesma similaridade mantida,
como pode ser visto na Tabela 5.6, a composio com a aplicao de loja de CDs foi realizada

116
em 10:59 e com a aplicao Abaco em 12:35. No se pode afirmar que a hiptese Ha
mostrada na Tabela 5.3 pode ser refutada, porm h mais indcios que sim do que no.
Sempre que problemas ocorriam durante a coleta dos dados, os participantes eram
instrudos a relatar o problema. Por exemplo, durante a realizao da primeira etapa da
primeira fase, o participante P2 realizou o acoplamento do comportamento de persistncia
(TACP) em 10 minutos, um valor bem acima da mdia dos outros participantes. Contudo, ele
relatou que teve problemas com o ambiente Eclipse e que demorou cerca de 7,5 minutos para
corrigir o problema. Note-se que se esse valor fosse descontado do tempo relatado pelo
participante, ele estaria na mdia. Isso no foi feito porque problemas desse tipo so comuns
durante qualquer desenvolvimento.
S.2.S - Anlise dos Dados
S.2.S.J Primeira Iase do Lstudo
Os dados coletados na primeira fase do estudo mostraram que a composio utilizando o FT
foi mais eficiente do que com o framework OO para 11 dos 12 participantes, como pode ser
observado na Figura 5.7. Nessa figura, cada par de colunas representa os tempos de
composio de um determinado participante. As colunas brancas representam o tempo gasto
na composio com o framework OO e as colunas cinza com o FT. As etiquetas sobrepostas
sobre cada par de colunas representam a diferena percentual entre os tempos. Por exemplo, o
participante P2 realizou a composio com o FT 42,8% mais rpido do que com o framework
OO. Note-se que apenas o participante P3 gastou mais tempo com o FT do que com o
framework OO, porm foi uma diferena muito pequena: 21 segundos. Analisando-se os
formulrios de coleta de dados desse participante no foi constatado nenhum problema.

Figura 5.7 Diferenas Percentuais entre os Tempos de Composio (Primeira Fase)
Eficincia Individual dos Participantes na Primeira Fase
19:00
17:05
21:00
12:00
10:51
11:15
14:01
12:35
11:05
09:36
24:00
13:02
19:00
12:00
06:54
03:44
14:40
13:08
17:51
11:25
16:05
09:39
26:00
16:00
00:00:00
00:02:53
00:05:46
00:08:38
00:11:31
00:14:24
00:17:17
00:20:10
00:23:02
00:25:55
00:28:48
T
e
m
p
o
P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12
8,4 42,8

9,5 10,2 13,3 31,4 36,8 45,8 10,4 36,0 40 38,4
117
Um fato interessante foi que os participantes com menos experincia em linguagens de
programao obtiveram um nvel de eficincia elevado com o FT. Por exemplo, o participante
P6 fez a composio com o FT 31,4% mais rpido do que com o FOO, e o participante P12
obteve um ndice ainda melhor, 38,4%.
Desconsiderando os participantes experientes (P1, P2, P7 e P8), a mdia de tempo de
composio dos novatos com o FT foi 23,65% menor do que usando o framework OO.
Mesmo se os dados dos participantes P6 e P12, que so inexperientes em programao, forem
desconsiderados, ainda assim os demais novatos foram 21,27% mais eficientes com o FT do
que com o framework OO.
Os participantes experientes tambm foram mais eficientes com o FT do que com o
framework OO. A mdia do tempo de composio foi 8,33% mais rpida com o FT do que os
novatos enquanto os experientes realizaram a composio com o FT 31,98% em mdia mais
rpido do que com o framework OO, a mdia dos novatos foi de 23,65%.
Apenas o P1 obteve uma diferena percentual pequena entre os tempos, como pode ser
observado na Figura 5.7. Porm, analisando-se os formulrios desse participante, pde-se
constatar que ele obteve problemas com o ambiente durante a composio com o FT, o que
elevou o tempo de composio com esse framework. Isso tambm pode ser constatado
observando que o tempo de composio usando o FT desse participante foi superior ao de
todos os outros participantes (17:05).
Sem considerar a diferena entre experientes e novatos, o tempo mdio de composio
do FT com a aplicao de loja de CDs foi de 10:59 (Tabela 5.6), um valor 34,1% menor do
que o tempo mdio de composio dessa mesma aplicao com o framework OO, que foi de
16:40 (Tabela 5.5). Da mesma forma, o tempo mdio de composio do FT com a aplicao
Abaco foi de 12:35 (Tabela 5.6), um valor 24,87% menor do que com o framework OO, que
foi de 16:45 (Tabela 5.5). Assim, a mdia de tempo utilizada pelos dois grupos para a
composio do FT foi de 11:47, enquanto que utilizando o framework OO foi de 16:42. O FT
foi 29,3% mais rpido em mdia do que com o framework OO nessa primeira fase do estudo.
S.2.S.2 Segunda Iase do Lstudo
Os dados obtidos na segunda fase do estudo podem ser vistos no grfico da Figura 5.8. Assim
como na Figura 5.7, as notas sobrepostas sobre cada par de colunas representam a diferena
percentual do tempo de composio usando cada um dos frameworks. Nesta fase, que s
envolveu participantes com experincia em POA, o tempo de composio com o FT foi
menor do que com o framework OO para todos os participantes. A eficincia mdia tambm
foi melhorada para os participantes experientes, enquanto que na primeira fase a composio

118
com o FT foi 31,98% mais rpida, nessa segunda fase foi de 37,37%. Uma diferena
provavelmente ocasionada pelo conhecimento do framework.
Considerando-se as mdias de tempo, a composio da aplicao Abaco com o
framework OO foi realizada em 20:39, enquanto que com o FT o tempo foi de 11:10, uma
diferena de 54,0% a favor da orientao a aspectos. J, com a aplicao de Loja de CDs a
diferena foi bem menor, mas ainda assim favoreceu o FT: a composio com o framework
OO foi realizada em 15:54, enquanto que com o FT foi realizada em 11:27, uma diferena de
27,98%.

Figura 5.8 - Diferenas Percentuais entre os Tempos de Composio (Segunda Fase)

A mdia de tempo utilizada pelos dois grupos de experientes para a composio do FT
foi de 11:18 nesta segunda fase, enquanto que na primeira foi de 11:12, uma diferena
insignificante. Embora tambm pequena, a diferena com o framework OO foi maior entre as
duas fases. Enquanto que na primeira fase a composio com o framework OO foi realizada
pelos experientes em 16:28 em mdia, na segunda foi realizada em 18:17.
S.2.6 Resultados Parciais
Como pode ser observado, tanto na primeira fase quanto na segunda, a mdia de tempo da
composio utilizando o FT foi menor do que utilizando o framework OO, mostrando
evidncias de que a hiptese H
0
mostrada na Tabela 5.2 talvez pudesse ser refutada se
experimentos formais fossem conduzidos.
Se os tempos forem analisados individualmente para cada um dos trs passos da
composio, tanto na primeira fase quanto na segunda, observa-se que a diferena de tempo
relevante ocorre na verdade durante o acoplamento da conexo, e no durante o acoplamento
do comportamento da persistncia ou dos testes.
Eficincia Individual dos Participantes na Segunda Fase
00:20:17
00:10:53
00:21:00
00:12:00
00:17:50
00:13:00
00:13:59
00:09:20
00:00:00
00:02:53
00:05:46
00:08:38
00:11:31
00:14:24
00:17:17
00:20:10
00:23:02
T
e
m
p
o
27,10 42,85 46,3
P1 P7
33,25
119
Na Tabela 5.8 mostrado o tempo mdio de cada um dos passos da composio para
as duas fases do estudo. Essas mdias foram obtidas calculando-se a mdia das mdias obtidas
para cada passo do estudo comparativo. Por exemplo, o tempo mdio de acoplamento do
comportamento da persistncia da primeira fase 03:40 com o framework OO (considerando
as duas aplicaes). Esse valor foi obtido calculando-se a mdia das mdias das duas
aplicaes com o mesmo framework, no fazendo distino entre experientes e novatos 3:42
e 3:37, como pode ser visto na terceira linha na Tabela 5.5. O mesmo foi feito para os demais
valores.
Tabela 5.8 Tempo Mdio dos Passos de Composio da Primeira e Segunda Fases
Primeira Fase
Composio com Framework OO
Mdia do Tempo de Acoplamento da Persistncia com FOO 03:40
Mdia do Tempo de Acoplamento da Conexo com FOO |--- 06:58 ---|
Mdia do Tempo de Realizao dos Testes com FOO 06:05
Composio com Framework Transversal
Mdia do Tempo de Acoplamento da Persistncia com FT 03:56
Mdia do Tempo de Acoplamento da Conexo com FT |--- 02:32 ---|
Mdia do Tempo de Realizao dos Testes com FT 05:20
Segunda Fase
Composio com Framework OO
Mdia do Tempo de Acoplamento da Persistncia com FOO 06:07
Mdia do Tempo de Acoplamento da Conexo com FOO |--- 06:32---|
Mdia do Tempo de Realizao dos Testes com FOO 05:37
Composio com Framework Transversal
Mdia do Tempo de Acoplamento da Persistncia com FT 03:41
Mdia do Tempo de Acoplamento da Conexo com FT |--- 02:45 ---|
Mdia do Tempo de Realizao dos Testes com FT 04:52

O passo de acoplamento da persistncia possui diferenas muito sutis de tempo entre
as verses OO e OA. A justificativa para isso que a quantidade de linhas de cdigo escritas
para realizar esse passo bastante similar entre as duas verses, como pode ser visto
comparando a Figura 5.1 com a Figura 5.2. A diferena entre as verses OO e OA que nessa
ltima todas as linhas de cdigo estaro em um nico aspecto e no espalhadas pelo sistema.
Dessa forma, pode-se deduzir que embora determinados interesses transversais tenham um
impacto significativo na manuteno e legibilidade do cdigo, influenciam minimamente o
tempo da composio.
Com base nesses dados, observa-se que a diferena de tempo significativa somente
ocorre no passo de acoplamento da conexo. Na primeira fase do estudo, o tempo mdio de
realizao desse passo usando o FOO foi de 6:58, enquanto que usando o FT foi de 2:32, uma
diferena de 63,63%. Na segunda fase a diferena foi de 57,90%.
Observando-se os dados coletados pde-se concluir que essa diferena de tempo est
diretamente relacionada com a quantidade de locais do cdigo que devem ser manipulados,
mas principalmente, com a quantidade de linhas de cdigo que so escritas para a realizao
do acoplamento. Tanto na primeira fase quanto na segunda, houve uma diferena significativa

120
na quantidade de linhas de cdigo escritas quando a conexo acoplada utilizando-se o FT,
fazendo com que o tempo de acoplamento diminua. Comparando-se a Tabela 5.5 e a 5.6
pode-se observar que a quantidade de linhas de cdigo escritas (LC) para o acoplamento da
aplicao de loja de CDs com o framework OO foi de 48 linhas, enquanto que o acoplamento
do FT com essa mesma aplicao utilizou entre 7 e 12 linhas. O mesmo ocorreu com a
aplicao Abaco, que utilizou 44 linhas de cdigo para o acoplamento com o framework OO e
entre 7 e 12 para o acoplamento com o FT.
Mesmo considerando a escrita de uma linha com orientao a aspectos mais difcil e
demorada do que a escrita de uma linha com orientao a objetos, a grande diferena na
quantidade de linhas escritas favorece a orientao a aspectos. Contudo, para interesses cuja
quantidade de linhas de cdigo escritas para o acoplamento similar entre as duas verses, a
orientao a objetos pode ser beneficiada. Note-se, por exemplo, o passo de acoplamento da
persistncia na primeira fase do estudo, que envolveu tanto participantes experientes quanto
novatos. Na Tabela 5.8 mostrado que a mdia de tempo usando orientao a objetos (3:40)
foi 6,7% mais rpida do que usando orientao a aspectos (3:56). Embora seja uma diferena
pequena, est diretamente relacionada com o tamanho das aplicaes usadas no estudo. Para
aplicaes maiores essa diferena tende a aumentar. Note-se tambm que na segunda fase do
estudo, que s envolveu participantes experientes, o tempo de realizao do primeiro passo
favoreceu a orientao a aspectos. Isso ocorre porque, para esse caso, a dificuldade de se
escrever uma linha de cdigo com orientao a aspectos similar dificuldade com
orientao a objetos.
Os grficos mostrados na Figura 5.9 apresentam uma comparao entre o nmero
mdio de linhas de cdigo escrito durante a composio com o framework OO e com o FT.
Cada coluna representa um passo da etapa de composio: a primeira o acoplamento da
persistncia e a segunda o acoplamento da conexo. As colunas brancas representam a
quantidade mdia de linhas de cdigo escritas durante a composio com o framework OO e
as cinza com o FT. Sobre cada coluna tambm encontrado o tempo mdio que os
participantes gastaram na realizao de cada um dos passos, sem fazer distino entre
experientes ou novatos. Os dois grficos da parte superior da figura correspondem primeira
fase e os dois da parte inferior correspondem segunda fase. Note-se que em todos os casos, a
quantidade de linhas de cdigo necessrias para se realizar o acoplamento da conexo maior
quando se utiliza o framework OO.
Os resultados da primeira e segunda fase do estudo mostraram uma pequena diferena
no tempo de composio a favor do FT, cerca de 4 minutos em mdia em ambas as fases, com
121
pode ser observado na Tabela 5.8. Embora seja uma diferena pequena, o tamanho das
aplicaes tem influncia direta sobre esse nmero. A composio do framework OO foi em
mdia 30% mais demorada do que com o FT tanto na primeira fase quanto na segunda.
Para muitas organizaes essa diferena pode ser insignificante, principalmente para
aquelas que trabalham com aplicaes de pequeno porte. Alm disso, para essas organizaes,
os recursos investidos no treinamento em uma nova tecnologia pode inviabilizar a adoo de
uma nova tcnica de programao. Contudo, observa-se que, como essa diferena de tempo
est ligada com a quantidade de locais modificados do cdigo, aplicaes de grande porte
podem se beneficiar com a adoo de um FT, embora novos experimentos devam ser feitos
para apresentar dados quantitativos mais slidos.

Figura 5.9 Comparao do Dado LC

Considerando apenas o passo de acoplamento da conexo a diferena percentual
bem maior. Por exemplo, na primeira fase do estudo, a mdia do tempo de acoplamento da
conexo usando o framework OO foi de 6:58, enquanto que com o FT foi de 2:32, uma
diferena de 63,64%, um nmero bastante significativo em se tratando de tempo. Um nmero
relativamente similar encontrado na segunda fase: 57,91%. Com essa ltima anlise pode-se
inferir que determinados interesses transversais que afetam um grande nmero de locais do
Composio com Aplicao de Loja de CDs - FOO e FT
Persistncia
OO; 10
Conexo OO;
48
Persistncia
OA; 8,83
Conexo
OA; 9,33
0
10
20
30
40
50
60
Acoplamento do Comportamento da Persistncia
e Acoplamento da Conexo
M
d
i
a

d
a

Q
u
a
n
t
i
d
a
d
e

d
e

L
i
n
h
a
s

d
e

C
d
i
g
o

E
s
c
r
i
t
a
s
Composio com Aplicao Abaco - FOO e FT
Persistncia
OO; 16
Conexo OO;
44
Persistncia
OA; 12,17 Conexo
OA; 9,83
0
10
20
30
40
50
60
M
d
i
a

d
a

Q
u
a
n
t
i
d
a
d
e

d
e

L
i
n
h
a
s

d
e

C
d
i
g
o

E
s
c
r
i
t
a
s
Composio com Aplicao de Loja de CDs - FOO e FT
Persistncia
OO; 10
Conexo OO;
42
Persistncia
OA; 10,50
Conexo
OA; 12
0
10
20
30
40
50
60
M
d
i
a

d
a

Q
u
a
n
t
i
d
a
d
e

d
e

L
i
n
h
a
s

d
e

C
d
i
g
o

E
s
c
r
i
t
a
s
Composio com Aplicao Abaco - FOO e FT
Persistncia
OO; 16
Conexo OO;
44
Persistncia
OA; 11,50
Conexo
OA; 9
0
10
20
30
40
50
60
M
d
i
a

d
a

Q
u
a
n
t
i
d
a
d
e

d
e

L
i
n
h
a
s

d
e

C
d
i
g
o

E
s
c
r
i
t
a
s

122
cdigo, como ocorre com a conexo, possuem uma diferena significativa no tempo de
composio.
S.2.7 Ameaas Validade do Lstudo
Um ponto que pode influenciar os resultados a forma de implementao dos frameworks.
Apesar dos frameworks utilizados no estudo seguirem basicamente a mesma estrutura da
maioria dos outros frameworks pesquisados na literatura, pode ser que haja alguma
implementao orientada a objetos que diminua o trabalho de acoplamento, e
conseqentemente o tempo total de acoplamento.
O fato de apenas a etapa de composio ter sido submetida anlise no influencia os
resultados, pois geralmente a etapa de instanciao de um framework, seja OO ou OA, feita
com mecanismos orientados a objetos. Com base nos resultados obtidos, infere-se que mesmo
se a etapa de instanciao de algum FT utilizasse mecanismos orientados a aspectos, o tempo
diminuiria, o que no inviabilizaria os resultados. Entretanto, experimentos formais precisam
ser conduzidos tambm nesse sentido.
Outro ponto que pode ter influenciado a utilizao de alunos de ps-graduao como
participantes do estudo. Contudo, procurou-se no influenciar os alunos demonstrando
expectativas a favor ou contra algum dos frameworks.
S.2.8 Concluso do Lstudo de Caso
Embora o estudo tenha sido realizado com frameworks, os resultados mostram indcios de que
o tempo de composio de outros interesses implementados com aspectos, desde que sejam
transversais, menor do que de um interesse implementado com orientao a objetos. Isso se
d pela quantidade de linhas de cdigo que devem ser escritas quando a implementao do
interesse se espalha pelos mdulos do sistema.
Aps a realizao do estudo concluiu-se que h diferena no tempo de composio
quando se utiliza orientao a aspectos. Em conseqncia da quantidade de linhas de cdigo
que deve ser escrita para realizar a composio, a orientao a aspectos beneficiada pelo
mecanismo de quantificao, em que vrios pontos de acoplamento so informados em
poucas linhas.
Note-se que os dados apresentados s so vlidos para frameworks caixa branca, em
que a composio realizada com acesso ao cdigo-fonte do framework. No caso de
frameworks caixa preta o tempo de composio passa a ser algo irrelevante, pois ser
realizado rapidamente independentemente se a implementao feita com orientao a
aspectos ou no.
123
Como trabalhos futuros, pretende-se replicar o experimento para aplicaes maiores,
com o objetivo de averiguar se o tempo de composio continua aumentando conforme o
tamanho da aplicao. Alm disso, pretende-se tambm realizar o mesmo tipo de experimento
com outros frameworks, por exemplo, controle de acesso, autenticao e frameworks que
tratam de requisitos funcionais.
Espera-se que o pacote de experimentao, que est disponvel em
www.icmc.usp.br/~valter, seja utilizado por outros pesquisadores e/ou profissionais em novos
experimentos que utilizam aplicaes de grande e mdio porte.
S.3 ANLISL DA DIIICULDADL DL ACOPLAMLN1O
Nesta seo apresentado um segundo estudo conduzido em uma disciplina de ps-graduao
do ICMC/USP So Carlos no primeiro semestre de 2005 (Camargo e Masiero, 2005c). O
objetivo foi averiguar a dificuldade de localizar um ponto de juno em um cdigo-base
(aplicao) que no segue boas prticas de programao. Vale ressaltar que foi considerado
que os participantes no possuam acesso ao cdigo-fonte do sistema. Assim, nenhuma
modificao poderia ser feita.
O FT utilizado no estudo foi o de Clculo Baseado em Tabela, que foi exemplificado
no Captulo 3. Para a realizao do estudo foi obtida na Internet uma aplicao com cdigo
desestruturado, o que permitiu simular situaes reais do cotidiano, em que no h garantias
da utilizao de boas prticas de programao e/ou padres de projeto (Gamma et al., 1995).
A aplicao utilizada no estudo um sistema de caixa de banco em que clientes
podem ser adicionados e contas podem ser criadas. Tambm possvel realizar depsitos e
retiradas nas contas. O sistema est implementado em Java e utiliza banco de dados MySQL.
Embora os participantes tivessem acesso ao cdigo fonte da aplicao, ele no poderia ser
modificado para a realizao do acoplamento. O modelo de classes da aplicao mostrado
na Figura 5.10.
Os participantes do estudo deveriam realizar uma operao de manuteno na aplicao.
O tipo da evoluo a adio (enhancive), que consiste em modificaes e adies no
conjunto de regras de negcio implementadas pela aplicao. Isso pode ocorrer por meio da
insero de novos componentes, algoritmos ou subsistemas e at alterando os existentes para
aumentar ou estender o seu escopo (Chapin et al., 2001).
A nova regra de negcio que deveria ser adiconada na aplicao era a seguinte: toda
vez que uma nova conta fosse criada com um valor acima de R$ 5.000,00, haveria um prmio
de 1% do valor depositado que seria adicionado no valor da conta. Por exemplo, se uma conta

124
fosse criada com um valor de R$ 10.000,00, o valor que realmente haveria na nova conta seria
R$ 10.100,00.

Figura 5.10 Diagrama de Classes do Sistema de Caixa de Banco
Trs alunos participaram do estudo. Os trs possuam o mesmo nvel de conhecimento
da linguagem Java, mas nunca haviam tido contado com os conceitos da programao
orientada a aspectos, portanto foi realizado um treinamento com os novos conceitos, com a
linguagem AspectJ e com o FT de clculo baseado em tabela.
Na Tabela 5.9 so mostrados os tempos que foram gastos com cada atividade de cada
etapa do processo de reso do framework. Como pode ser observado, a etapa de instanciao
foi realizada rapidamente pelos alunos. Para cada atividade, marcou-se o tempo de estudo do
manual (coluna manual) e de implementao (coluna impl). Os questionrios e relatrios
podem ser encontrados no Anexo 3 desta tese.
A segunda etapa foi a que consumiu mais tempo. As primeiras trs atividades dessa
etapa foram realizadas rapidamente. O problema ocorreu na atividade 4, em que os alunos
deveriam identificar na aplicao-base um ponto de juno que fosse adequado ao
acoplamento com o framework. Para realizar essa identificao, o manual do framework
dispe do modelo de deciso apresentado na Tabela 3.2. Esse modelo auxilia o engenheiro de
aplicao a escolher por uma alternativa de composio adequada do framework.
Analisando os relatrios dos alunos (Anexo 3), observou-se que a demora na
identificao do ponto de juno mais adequado foi a qualidade da aplicao-base. O cdigo
do sistema de gerenciamento de contas no seguia boas prticas de programao, violando
princpios bsicos da programao orientada a objetos, o que dificultava a identificao do
ponto de juno ideal.
BankBox
addCl i ent()
createAccount()
getConnecti on()
setConnecti on()
l oadCl i ents()
removeCli ent()
removeAccount()
l oadAccount()
Account
save()
Cl i ent
l oadAccounts()
removeAccount()
save()
0..n
1
0..n
1
125
Como o framework deveria capturar o valor da conta quando essa era criada, o local
mais adequado parecia ser o mtodo createAccount() da classe BankBox (Figura 5.11), j
que esse mtodo possui um parmetro chamado Value, que o valor da conta. Contudo, uma
anlise na documentao do framework revela que no h uma alternativa de composio que
possa ser utilizada para capturar um tipo primitivo do parmetro e modific-lo. Na verdade, a
captura do valor e sua modificao at pode ser feita, porm como a passagem de parmetros
de tipos primitivos em Java feita por valor, a modificao efetuada dentro do framework no
refletida no cdigo da aplicao. A alternativa TBargs poderia ser utilizada se o parmetro
fosse um objeto que contivesse um atributo representando o valor sujeito ao clculo.
Tabela 5.9 Tempo de Cada Atividade

Etapa de Reso Aluno1 Aluno2 Aluno3
Instanciao Manual Impl manual Impl manual impl
1 Escolher variabilidade 00:15 00:04 00:15 00:05 00:18 00:02
2
Criar a camada de
instanciao 00:03 00:02 00:01 00:01 00:10 00:01
3
Implementar
Variabilidade 00:02 00:04 00:03 00:05 00:14 00:07
4 Criar Tabela 00:05 00:14 00:05 00:05 00:03 00:04
A
t
i
v
i
d
a
d
e
s

5 Preencher a Tabela 00:18 00:14 00:01 00:06 00:02 00:05
Total Parcial 00:43 00:38 00:25 00:22 00:47 00:19
Tempo da Etapa 1 01:21:00 00:47:00 01:06:00
Etapa Composio Aluno1 Aluno2 Aluno3
1
Definir Mapeamento
OO-Relacional 00:08 00:07 00:04 00:09 00:06 00:07
2
Definir Variabilidades de
conexo 00:10 00:08 00:01 00:04 00:04 00:05
3 Determinar conexo 00:06 00:07 00:03 00:03 00:03 00:06
4
Identificar Ponto de
juno 01:25 03:00 00:32 02:11 00:20 06:10
A
t
i
v
i
d
a
d
e
s

5
Fornecer regras de
composio 00:30 00:40 00:05 01:35 00:40 01:05
Tota Parcial 02:19 04:02 00:45 04:02 01:13 07:33
Tempo da Etapa 2 06:21 04:47 08:46
Tempo Total 07:42 05:34 09:52

Outro ponto de juno que parecia ser conveniente era a chamada do mtodo
setValue(), destacado em negrito na Figura 5.11. Como o objeto alvo da chamada um
objeto Account, a alternativa de composio TBTarget poderia ser utilizada para capturar o
objeto alvo Account, recuperar o valor da conta e modific-lo. Entretanto, o problema foi
que neste momento da execuo, o valor da conta j havia sido inserido no banco de dados,
como pode ser visto na parte do cdigo destacada com um retngulo, e no adiantava mais

126
alterar o seu valor apenas em memria. Uma estratgia de implementao muito ruim para um
programa orientado a objetos.
Depois de muitas tentativas de acoplamento em locais errados, o engenheiro do
framework indicou aos alunos o ponto de juno correto, que mostrado na Figura 5.12. O
mtodo getText() do objeto value captura da interface grfica o valor da conta que est
sendo criada na forma de uma String e em seguida o mtodo parseDouble() o converte
para o tipo Double. Como a alternativa de composio OneArgument exige que o ponto de
juno seja uma chamada/execuo de um mtodo cujo nico parmetro seja uma String (que
o valor sujeito ao clculo), a chamada ao mtodo parseDouble() um ponto de juno
que pode ser utilizado para o acoplamento. Depois que o ponto de juno foi informado aos
alunos, o acoplamento foi feito rapidamente.

Figura 5.11 Mtodo CreateAccount()
Os alunos comentaram que uma das maiores dificuldades para identificar o ponto
correto de acoplamento foi a falta de qualidade no cdigo da aplicao e a falta de
relacionamento semntico que o ponto de juno tinha com o negcio em si. Como pode ser
visto na Figura 5.12 a chamada do mtodo parseDouble() realmente no semanticamente
relacionada com o objetivo do acoplamento, e sim uma chamada de mtodo para converso de
valores. Segundo os alunos, algo que tambm dificultou a identificao foi que a chamada ao
mtodo parseDouble() era um parmetro do mtodo createAccount() da classe
BankBox, e no estava claro no manual que isso poderia ser feito.
Embora no tenha sido realizado nenhum experimento controlado com uma aplicao-
base bem estruturada, a experincia do autor desta tese com o desenvolvimento de FTs tm
revelado um tempo menor de acoplamento. Isso tambm pode ser inferido pelo estudo
public class BankBox {
...
public Account createAccount(int clientId, double Value..) {
Account retValue = null;
//insere dados da nova conta no B.D.
Statement stm = null;
String sql = "INSERT INTO ACCOUNTS (CLIENT_ID, ACTUAL_TYPE, ACTUAL_VALUE,
DESCR) VALUES ("+clientId+",'"+type+"',"+value+",'"+descr+"')";
stm = this.getConnection().createStatement();
stm.executeUpdate(sql);
stm.close();
this.getConnection().commit();
//cria nova conta.
Account account = new Account(this.getConnection(), clientId);
account.setType(type);
account.setValue(value);
account.setDescr(descr);

//adiciona conta criada ao vetor de contas.
this.accounts.add(account);

refreshTables();

...
}
127
mostrado aqui. O primeiro ponto de juno que os trs alunos tentaram foi a chamada do
construtor da classe Account dentro do mtodo createAccount() (Figura 5.11). Se os
comandos de insero no banco de dados no estivessem antes dessa chamada, (como deveria
ser em um cdigo bem estruturado), o tempo de acoplamento seria muito menor. Outra
evidncia que depois que o engenheiro do framework informou qual era o ponto, os alunos
realizaram o acoplamento rapidamente, em um mdia de dois minutos.

Figura 5.12 Ponto de Juno Real do Cdigo-Base
S.4 LS1UDOS PARA APOIAR O DLSLNVOLVIMLN1O L
1LS1LS DOS I1S
Outros estudos informais foram conduzidos durante o programa de doutorado com o objetivo
de testar e aprimorar os frameworks. No segundo semestre de 2003 quatro alunos de uma
disciplina de ps-graduao desenvolveram parte de um sistema de uma clnica veterinria
utilizando o FT de persistncia. Nesta poca, o FT de persistncia ainda era bastante
prematuro (Camargo et al., 2003) e o estudo foi bastante til para evidenciar alguns
problemas que ele possua. A modificao mais radical que foi realizada em sua arquitetura
foi a utilizao de reflexividade para realizar o mapeamento objeto-relacional. At ento, cada
classe de aplicao persistente deveria possuir um aspecto que era responsvel pelo
mapemento. Depois desse estudo, eliminou-se a necessidade de criar um aspecto para cada
classe persistente de aplicao. H apenas um aspecto responsvel pelo mapeamento.
No segundo semestre de 2004 os alunos de uma outra disciplina participaram de um
estudo que envolvia a utilizao dos frameworks de persistncia e de segurana. O exerccio
consistia no desenvolvimento de uma aplicao de gerenciamento de contas bancrias. Um
relatrio deveria ser prenchido pelos alunos ao fim do exerccio, o qual pode ser visto no
Anexo 4. Esse estudo teve um objetivo mais abrangente, que foi averiguar o processo, o
tempo gasto em cada fase do processo, o manual e colher comentrios sobre os frameworks
de persistncia e de segurana. Embora vrios comentrios e sugestes importantes tenham
public class AccountsFieldsPanel extends JPanel implements ActionListener {

...
public void actionPerformed(ActionEvent e) {
...
Account account = bankBox.createAccount(Integer.parseInt(
clientId.getText().trim()),
type.getText().trim(),
Double.parseDouble(value.getText().trim()),
descr.getText());
...
}
...
}


128
sido feitos pelos alunos, o experiento em si no foi muito satisfatrio. Problemas ocorreram
com a configurao do ambiente, o que influenciou muito o tempo gasto em cada uma das
fases do processo.
No geral, seis aplicaes foram desenvolvidas durante o programa de doutorado com o
intuito de testar os frameworks, as quais podem ser vistas na Tabela 5.10. O smbolo marca
os FTs que foram utilizados em cada uma das aplicaes.
Tabela 5.10 Aplicaes Desenvolvidas

Applications

lrameworks
Oicina de
Aparelhos
Lletronicos
lolha de
Pagamento
Loja de
Vendade
CDs
Gerenciamento
de Contas
Bancarias
Caixa
Lletronico
lotel
Persistence

Caching - all tuples

Caching - object loader

Connection

Pooling

Access control

Authentication

Authentication policies

Access log

1able-based calculation

Value readjustment

1racing

Policy enorcement

S.S CONSIDLRALS IINAIS
O estudo de caso apresentado na Seo 5.4 foi conduzido no contexto de uma operao de
manuteno, mostrando que possvel realizar manuteno evolutiva com apoio de FTs
(Camargo e Masiero, 2005c). Contudo, a dificuldade na identificao do ponto de juno
revelou que melhores tcnicas deviam ser elaboradas para auxiliar o responsvel pela
manuteno, como por exemplo, um modelo de deciso mais elaborado, mais alternativas de
composio no FT, outros artefatos de projeto da aplicao-base, tcnicas de leitura, etc.
Outro ponto que poderia ser considerado em outros experimentos similares alterar o cdigo
da aplicao-base para facilitar o acoplamento. Entretanto, como o objetivo deste estudo era
realizar a manuteno sem modificaes invasivas, isso no foi permitido.
Um ponto que ainda precisa ser analisado o impacto de realizao de vrias
manutenes evolutivas com vrios frameworks, o que pode comprometer o desempenho e
tambm a qualidade da prpria aplicao. Tambm importante destacar que o uso freqente
do FT faz com que ele possa ser evoludo. Por exemplo, um dos alunos descreveu em seu
129
relatrio uma forma de fazer a composio sem utilizar as alternativas de composio do
framework. Esse comentrio revelou que o FT necessitava de mais uma alternativa de
composio.
No caso do estudo comparativo apresentado na Seo 5.3, a deciso por utilizar um FT
desenvolvido pelo prprio grupo de pesquisa se deu pelo acesso livre ao cdigo-fonte, e pelo
conhecimento total das funcionalidades disponveis no framework. Alm disso, o acesso ao
cdigo-fonte desse FT facilitou o desenvolvimento do framework OO de persistncia, j que
grande parte do cdigo foi reaproveitada. O desenvolvimento do framework OO com
funcionalidades idnticas faz com que o nvel de confiabilidade do estudo de caso aumente.
No faria sentido comparar o FT que j estava disponvel com o framework OO de
persistncia Hibernate (Hibernate, 2006), por exemplo, pois ambos possuem arquiteturas
diferentes, com funcionalidades e tcnicas de instanciao diferentes. Isso poderia acarretar
diferenas favorecendo ou prejudicando o tempo de composio de um dos frameworks.


130

Captulo 6
Pr o1,P| |v Pr oce.. o ae
De. e vrot ri ve vt o ae of t rar e aoi aao or
r ave ror /. 1r av.rer . ai .
Um processo de desenvolvimento de software orientado a aspectos apresentado neste
captulo. H quatro pontos que diferenciam este processo dos demais encontrados na literatura
(Clarke e Baniassad, 2005) (Jacobson e Ng, 2004). O primeiro que ele formado pela unio
de conceitos, critrios e tcnicas de modelagem de outros trabalhos j consagrados na
literatura e especializados em fases especficas do desenvolvimento (Clarke e Baniassad,
2005; Jacobson e Ng, 2004; Baniassad et al., 2006; Krechetov et al., 2006; Arajo e Moreira,
2003; Arajo et al., 2002). O segundo que ele fortemente baseado na identificao e
acopanhamento de interesses transversais durante o decorrer do processo. O terceiro que ele
apoiado por FTs em atividades especficas e, o quarto e ltimo que ele se trata de um
processo iterativo e incremental.
O processo denominado ProFT/PU e segue a estrutura de fases e disciplinas do
Processo Unificado (PU) (Jacobson et al., 1999) apresentado por Larman (2004). Dessa
forma, ele e iterativo e incremental, isto , o sistema desenvolvido em iteraes, em que
cada iterao se concentra no desenvolvimento de um subconjunto de casos de uso, at que o
sistema todo seja implementado.
ProFT/PU levemente influenciado pelos FTs desenvolvidos no contexto desta tese,
pois algumas atividades, como a identificao de aspectos, leva em conta a existncia de FTs
que possam ser utilizados para apoiar a implementao de um determinado interesse
transversal. Entretanto a implementao independente dos FTs, isto , pode ser feita de
Captulo 6 ProFT/PU

132
forma convencional, sem o uso de frameworks. No Captulo 7 o processo ilustrado com o
desenvolvimento de um sistema de reservas de uma rede de hotis.
Na Seo 6.2, uma viso geral do ProFT/PU apresentada. Na Seo 6.3, a fase de
Concepo descrita e na Seo 6.4 o enfoque dado fase de Elaborao. Na Seo 6.5 a
fase de Construo comentada e na Seo 6.6 as consideraes finais so realizadas.
6.2 VISO GLRAL DO PROI1/PU
O ProFT/PU tem como objetivo apoiar o desenvolvimento de um sistema de software
orientado a aspectos por meio de diretrizes, disciplinas (em verses anteriores do PU
chamadas de fluxos de trabalho (workflow)) e um repositrio que consiste em famlias de FTs.
Assim como o PU, o ProFT/PU iterativo e orientado pelos riscos e as atividades que
devem ser realizadas so acomodadas dentro das fases do PU, que podem ser vistas na Figura
6.1. Na fase de concepo, uma viso aproximada do sistema criada, casos de uso funcionais
e no funcionais simples so elaborados e algumas estimativas so delineadas. Na elaborao,
os primeiros interesses transversais so identificados, a viso do sistema refinada, a
arquitetura central implementada iterativamente, a maioria dos requisitos identificada e os
casos de uso que sero implementados como aspectos so escolhidos. Em cada uma das
iteraes da fase de elaborao, os casos de uso selecionados para a iterao atual so
projetados e adicionados aos casos de uso j desenvolvidos, gerando uma verso executvel.
Na fase de construo implementa-se iterativamente os elementos restantes de menor risco e
prepara-se para a implantao. Na fase de transio so realizados testes e a implantao
propriamente dita conduzida (Larman, 2004). Vale ressaltar que a fase de transio no
coberta pela pesquisa apresentada nesta tese.
O PU baseado em um conjunto de disciplinas que devem ser realizadas, como por
exemplo, requisitos, anlise, projeto e implementao. Essas disciplinas se repetem dentro de
todas as fases, porm com nfases diferentes conforme o processo progride. Dependendo da
fase, a nfase nessas disciplinas maior ou menor. Por exemplo, na fase de concepo, a
nfase dada na disciplina de requisitos maior do que na fase de construo. Nas fases
iterativas, por exemplo, na elaborao e na construo, as primeiras iteraes possuem uma
nfase maior na anlise e projeto, enquanto que nas ltimas iteraes a nfase maior na
implementao. Na Figura 6.2 so mostradas as disciplinas do PU e a nfase que deve ser
dada durante o desenvolvimento representada pela rea das formas abstratas.
Captulo 6 ProFT/PU
133

Figura 6.1 As Fases do ProFT/PU

ProFT/PU
Disciplinas Concepo Elaborao Construo
Requisitos
Anlise
Projeto
Implementao
Teste

Figura 6.2 Viso Geral do ProFT/PU
O ProFT/PU utiliza a mesma estrutura de processo do PU, porm possui atividades
especficas para o tratamento de interesses transversais. Na Tabela 6.1 so mostradas as
atividades do ProFT/PU em cada disciplina. As atividades que esto em negrito so
particulares deste processo de desenvolvimento. J as atividades que no esto em negrito so
normais a qualquer processo de desenvolvimento baseado no PU, mas possuem alguma
modificao ou influncia das demais atividades ou da existncia dos FTs. Essas atividades
podem ocorrer em qualquer uma das fases do PU, porm mais comum que as atividades da
disciplina Requisitos, por exemplo, sejam executadas mais na Concepo do que na
Construo.
Nas subsees seguintes so descritas as atividades mostradas na Tabela 6.1. Essas
atividades so detalhadas em cada disciplina de cada fase do PU onde so mais provveis de
ocorrer.
6.3 IASL DL CONCLPO
A fase de concepo deve ser relativamente curta para a maioria dos projetos e no realizada
em iteraes, tendo geralmente uma ou poucas semanas de durao. O propsito estabelecer
Concepo
Elaborao
Construo
Transio
Iterao
Iterao
Iterao
Tempo
Captulo 6 ProFT/PU

134
uma viso inicial comum para os objetivos do projeto, determinar se vivel e decidir se
realmente deve passar por uma investigao mais profunda na fase de elaborao. Como a
disciplina que possui mais modificaes dentro desta fase a de requisitos, esta seo mostra
apenas as atividades que devem ser realizadas nessa disciplina.
Tabela 6.1 Atividades do ProFT/PU
Atividades da Disciplina Requisitos
Identificar Atores e Detalhar Casos de Uso Funcionais
Identificar e Especificar Casos de Uso No-Funcionais
Planejar Iteraes
Atividades da Disciplina Anlise
Identificar e Registrar Casos de Uso Colaboradores
Identificar e Registrar Casos de Uso Candidatos a Aspectos
Criar Diagramas de Seqncia do Sistema
Definir Contratos das Operaes do Sistema
Desenvolver Modelo Conceitual
Atividades da Disciplina Projeto
Identificar Aspectos
Selecionar Aspectos para a Iterao Atual
Projetar Aspectos
Acoplar Aspectos com a Base
Desenvolver Diagramas de Interao
Desenvolver Modelo de Classes de Projeto
Projetar Modelo de Dados
Atualizar Regras de Composio
Desenvolver Modelo de Projeto Composto
Desenvolver Viso da Arquitetura
Registrar Pontos de Juno
Atividades da Disciplina Implementao
Implementar Classes de Domnio
Implementar Banco de Dados
Atualizar Regras de Composio
Implementar Aspectos
Implementar Classes Controladoras
Implementar Interfaces
Testar
6.3.J Disciplina Requisitos
Na Figura 6.3 so mostradas as atividades da disciplina de Requisitos juntamente com os
artefatos de entrada e sada de cada uma. Nesta e em outras figuras que aparecem no decorrer
deste captulo utilizada a notao SADT (Ross, 1977), cuja legenda pode ser vista na parte
inferior da figura. As atividades marcadas com a letra M possuem alguma modificao em
relao forma tradicional. Essas modificaes podem ser, por exemplo, decises
influenciadas pela existncia dos FTs. As atividades que possuem a letra N so atividades
novas, particulares deste processo de desenvolvimento; e as que no possuem marcao no
foram modificadas e podem ser conduzidas de forma convencional. Esta disciplina a que
tem mais nfase dentro da fase de Concepo, pois nela que os requisitos so especificados.
As prximas subsees descrevem as atividades desta disciplina.
Captulo 6 ProFT/PU
135

Figura 6.3 Atividades Da Disciplina Requisitos que Despendem Maior Esforo na Concepo
6.3.J.J Identificar Atores e Detalhar Casos de Uso Iuncionais
A identificao de casos de uso deve ser feita de forma que um conjunto inicial de
casos de uso possa ser obtido rapidamente, fornecendo uma viso de alto nvel das
funcionalidades do sistema. Embora no seja comum nesta altura do processo, tambm podem
ser identificados casos de uso colaboradores, que so os que colaboram para a realizao do
comportamento de um outro caso de uso, denominado base, relacionando-se a ele.
Os dois tipos mais comuns de relacionamentos entre casos de uso base e
colaboradores so o de incluso que utiliza o esteretipo <<include>> e o de extenso
que utiliza o esteretipo <<extend>>. O relacionamento de incluso ocorre quando o caso de
uso colaborador possui funcionalidade que parte integrante do comportamento do caso de
uso base, isto , sempre que o caso de uso base for executado, o caso de uso colaborador
tambm ser. J o relacionamento de extenso ocorre quando uma determinada
funcionalidade acrescentada ao comportamento de um caso de uso base j existente,
modificando o seu comportamento.
Note-se que o caso de uso base auto-suficiente, isto , seu comportamento principal
pode ser executado independentemente da presena do caso de uso que o estende. Uma forma
de se entender um relacionamento de extenso imaginar o caso de uso base sendo executado
sem o comportamento do caso de uso colaborador. Se fizer sentido, ento pode-se dizer que o
Identificar Atores e
Detalhar Casos de
uso Funcionais
Identificar e
Especificar Casos de
Uso No-Funcionais
Planejar
Iteraes
Atividades da Disciplina Requisitos
Doc.
Requisitos
Interessados
no sistema
- 1abela de Correspondncia
Caso de Uso,Requisito
- Diagrama de Casos de Uso
- 1abelas de Descriao de Casos de Uso Nls
- Diagrama de Casos de Uso Atualizado
- 1abela de Interesses 1ransersais Nao-luncionais
1abela de
Classiicaao e
Planejamento Interessados
no sistema
Atividade
Dados de Sada
Legenda Notao SAD1 (Ross, J977)
Dados de Controle
Mecanismos
Dados de Lntrada
Doc.
Requisitos
Lxperincia
Lxperincia
M
N
M
Captulo 6 ProFT/PU

136
caso de uso colaborador estende o caso de uso base. As definies mais antigas desse tipo de
relacionamento enfatizam que ele deve ser utilizado apenas para comportamentos opcionais,
isto , comportamentos que s so executados se uma determinada regra for verdadeira.
Definies mais recentes (Jacobson e Ng, 2004) mostram que ele tambm pode ser utilizado
para comportamentos que no so opcionais, isto , que so executados toda vez que o
comportamento base executado.
A diferena desta atividade em relao s tradicionais que, alm dos relacionamentos
de incluso e de extenso, sugere-se que tambm sejam utilizados os relacionamentos de
generalizao que utilizam o esteretipo <<generalize>> e os relacionamentos de restrio
que utilizam o esteretipo <<constrain>>. O relacionamento de generalizao ocorre
quando um caso de uso uma generalizao de dois ou mais casos de uso presentes no
sistema. J o relacionamento de restrio ocorre quando algum caso de uso restringe o
comportamento de outro caso de uso, como ocorre com restries de tempo, de desempenho e
de segurana (Arajo e Moreira, 2003; Arajo et al., 2002). Por exemplo, pode haver um caso
de uso que impe a restrio de que o caso de uso Calcular Folha de Pagamento no deve
exceder 15 minutos. Tambm pode haver um caso de uso de controle de acesso que restringe
o acesso a uma funcionalidade de gerao de relatrios de custos. Esse tipo de relacionamento
mais aplicvel para requisitos no-funcionais.
Depois que os casos de uso foram identificados e especificados sugere-se iniciar a
elaborao do artefato Tabela de Correspondncia Caso de Uso/Requisitos (TCCaU-R),
utilizando o modelo mostrado na Tabela 6.2. Esse artefato iniciado nesta atividade e ser
continuamente atualizado nas fases posteriores deste processo, facilitando o acompanhamento
do progresso do processo. Essa tabela permite registrar os casos de uso identificados at o
momento e os requisitos que deram origem aos casos de uso. A coluna proprietrio do
representa um relacionamento de propriedade entre o caso de uso e o requisito. Os
relacionamentos de propriedade so aqueles em que o caso de uso corresponde a exatamente
um requisito, isto , o caso de uso foi gerado com base em um requisito numerado do
documento de requisitos e por isso seu objetivo principal satisfazer quele requisito. Nesse
caso, diz-se que o caso de uso proprietrio do requisito, caracterizando um relacionamento
de propriedade entre eles. A coluna Colabora com deve listar os casos de uso que possuem
um relacionamento de colaborao com o caso de uso em questo. Um relacionamento de
colaborao ocorre quando a funcionalidade de um caso de uso utilizada como parte do
comportamento de um outro caso de uso mais geral. Assim, diz-se que o caso de uso mais
especfico colabora para a realizao do comportamento do caso de uso mais geral. Na Tabela
Captulo 6 ProFT/PU
137
6.3 mostrado um exemplo da Tabela de Correspondncia Caso de Uso/Requisitos do
sistema de reservas que ser exemplificado no captulo seguinte.
Tabela 6.2 Modelo para Tabela de Correspondncia Caso de Uso/Requisitos
Tabela de Correspondncia Caso de Uso/Requisitos
Caso de Uso D.C.U
N
o.
Descrio
proprietrio do Colabora com

1 Nome do caso de uso 1 Nmero do Req ---
2 Nome do caso de uso 2 Numero do Req. Nome do Caso
de Uso

6.3.J.2 Identificar e Lspecificar Casos de Uso No-Iuncionais
Esta atividade particular do ProFT/PU e o objetivo identificar e especificar os casos de uso
no-funcionais do sistema. O processo de identificao consiste em analisar o documento de
requisitos em busca de interesses/requisitos no-funcionais clssicos da literatura, como por
exemplo: Persistncia, Concorrncia, Autenticao, Controle de Acesso, Distribuio,
Tratamento de Excees, Memria Auxiliar, Criptografia e Sincronizao.
Dependendo do formato do documento de requisitos, pode haver sees especficas
para os interesses no-funcionais, o que facilita essa identificao. Entretanto, isso pode no
ocorrer e a experincia do engenheiro de software pode ser fundamental para o sucesso desta
atividade. Alguns interesses no-funcionais, como, por exemplo, desempenho, podem no
levar criao de casos de uso porque sua implementao pode implicar, por exemplo, na
escolha de melhores algoritmos, e no em trechos de cdigo que podem afetar a estrutura da
aplicao.
Tabela 6.3 Tabela de Correspondncia Caso de Uso/Requisitos Fase de Concepo
Tabela de Correspondncia Caso de Uso/Requisitos
Caso de Uso D.C.U
N
o.
Descrio
proprietrio do Colabora com

1 Gerenciar Hotel Req. 1
2 Gerenciar Acomodao Req. 2
3 Gerenciar Tipo de Acomodao Req. 3
4 Gerenciar Clientes Req. 4
5 Gerenciar Usurios Req. 5
6 Fazer Reserva Req. 6
7 Cancelar Reserva Req. 7
8 Alterar Reserva Req. 7
9 Ocupar Reserva Req. 8
10 Gerar dados para faturamento Req. 9 Ocupar
Reserva,
No
comparecer

11 Gerenciar Empresas Req. 10
12 No Comparecer Req. 9
13 Reajustar o Valor das Dirias Req. 10
14 Consultar se acomodao est
disponvel
Req. 11
15 Consulta nmero de reservas Req. 12
Captulo 6 ProFT/PU

138
Embora a identificao dos interesses no-funcionais parea simples, muitas vezes a forma
como o documento de requisitos escrito e o uso incorreto de termos pode esconder
requisitos relevantes.
Neste ponto do desenvolvimento deve ser iniciada a elaborao da Tabela de
Interesses Transversais No-Funcionais, como mostra o modelo na Tabela 6.4. Essa tabela
utilizada para documentar os interesses no-funcionais identificados at o momento e sua
correspondncia com os requisitos numerados do documento de requisitos.
Depois que os casos de uso no-funcionais foram identificados, devem ser
especificados e integrados no diagrama de casos de uso obtido at o momento. Para
especificar uma descrio mais detalhada de seu comportamento, deve-se entrevistar o
responsvel pelo sistema ou revisitar o documento de requisitos. Note-se que o objetivo no
obter uma descrio muito detalhada do caso de uso, mas sim refinar sua descrio original do
documento de requisitos para compreender melhor o seu comportamento. Nas fases
posteriores do processo, essas descries podem ser aprimoradas com detalhes sobre a
tecnologia e arquitetura do sistema se for necessrio.
Tabela 6.4 - Modelo para Tabela de Interesses Transversais No-Funcionais
Interesses No-Funcionais Identificados
Interesse No-Funcional Requisitos Cobertos
Interesse NF 1 1,2,3
Interesse NF 2 1,5,6

Para documentar os casos de uso no-funcionais, deve-se iniciar a elaborao da
Tabela de Descrio de Caso de Uso No-Funcional, como o modelo mostrado na Tabela 6.5,
para cada interesse no-funcional. Nessa tabela deve ser feita uma descrio refinada cujo
objetivo explicar o funcionamento do caso de uso no-funcional. Essa descrio pode ser
tanto um cenrio de uso do sistema, quanto uma descrio mais direta que mostre os
requisitos desse caso de uso. A elaborao dessa descrio geralmente exige que sejam feitas
entrevistas com os interessados no sistema, pois muitos detalhes so difceis de serem obtidos
apenas por meio do documento de requisitos.
Tabela 6.5 Modelo para Tabela de Descrio de Caso de Uso No-Funcional
Caso de Uso No-Funcional: - Nome do caso de uso
Casos de Uso Relacionados: - Casos de uso que so afetados por este caso de uso no-funcional
Descrio Original: - Descrio original encontrada no documento de requisitos
Descrio Refinada: - Descrio refinada

medida que uma Tabela de Descrio elaborada para um determinado caso de uso,
pode-se paralelamente incluir esse caso de uso no diagrama de casos de uso. O
Captulo 6 ProFT/PU
139
relacionamento que os casos de uso no-funcionais mantm com os outros casos de uso de
restrio (constrain), indicando que o caso de uso no-funcional afeta ou restringe o
comportamento do outro caso de uso (Arajo e Moreira, 2003; Arajo et al., 2002).
Com relao ao diagrama de casos de uso, aconselha-se a elaborao de vises
individuais tanto para os casos de uso no-funcionais, quanto para os casos de uso funcionais.
Essas vises individuais auxiliam na legibilidade do modelo. Por exemplo, na Figura 6.4
mostrada a viso individual do caso de uso hipottico Autenticar Usurio. A presena de
outros casos de uso no-funcionais neste diagrama poluiria o modelo e dificultaria o
entendimento.
6.3.J.3 Planejar Iteraes
Nesta atividade o objetivo planejar o nmero de iteraes que sero realizadas e alocar os
casos de uso que devem ser implementados em cada iterao. Para isso, o primeiro passo
classificar os casos de uso identificados at o momento. Assim como no PU, os casos de uso
relacionados com a funcionalidade principal do sistema e que apresentam riscos ao projeto
devem ser implementados nas primeiras iteraes da fase de elaborao, enquanto que os
casos de uso que oferecem menos riscos ao projeto podem ser implementados nas ltimas
iteraes.

Figura 6.4 Caso de Uso No-Funcional Autenticar Usurio Viso Individual de Caso de Uso No-
Funcional
Os casos de uso no-funcionais no devem ser levados em conta nessa classificao
para que o enfoque seja nos casos de uso funcionais. Entretanto, apesar de no serem
considerados durante a classificao, decises arquiteturais e/ou de projeto podem fazer com
que eles devam ser implementados logo nas primeiras iteraes para dar apoio aos casos de
Gerar dados para faturamento
Admi ni strador
Ocupar Reserva
<<i nclude>>
No Comparecer
<<include>>
Gerenci ar Usuri os
<<N...
Consultar Numero de Reservas
Consult ar Reservas Di a/Peri odo
Reajustar Val or de di ri as
Usuario
Aut ent icarUsuari o
<<NF>>
<<constrai n>>
<<constrai n>>
<<constrai n>>
<<constrai n>>
<<constrain>>
<<constrai n>>
Captulo 6 ProFT/PU

140
uso funcionais. Uma situao comum o replanejamento da iterao seguinte, tendo que
considerar casos de uso funcionais e/ou no-funcionais que no haviam sido considerados
anteriormente. Note-se que casos de uso gerenciadores de dados
20
so considerados
funcionais no contexto desta tese e devem ser considerados durante a classificao.
Um problema que pode ocorrer com a classificao inicial obtida que geralmente os
casos de uso das posies iniciais da lista precisam trabalhar com conceitos persistentes que
ainda no foram implementados. Isso ocorre porque os casos de uso gerenciadores de dados
desses conceitos geralmente encontram-se em posies intermedirias da classificao, e por
isso, sua implementao s ocorrer nas iteraes intermedirios e finais.
H duas alternativas para solucionar este problema. A primeira manter a
classificao como est e simular a persistncia dos conceitos at que os casos de uso
gerenciadores de dados sejam implementados, inserindo manualmente registros no banco de
dados ou trabalhando com dados em memria voltil, como feito por Soares (Soares, 2004).
A segunda deslocar os casos de uso gerenciadores de dados para as posies iniciais da lista
e implement-los antes que os conceitos sejam utilizados. Isso implica em considerar a
persistncia logo na primeira iterao. Quando no h um framework de persistncia
disponvel, geralmente a primeira alternativa adotada pela dificuldade em implementar do
zero o requisito no-funcional de persistncia. Como o processo descrito por este documento
apoiado por um FT de persistncia, a segunda alternativa torna-se mais factvel, pois uma
verso operacional do sistema ser obtida j com a arquitetura real que ser utilizada no
sistema final. Um problema de se utilizar uma tcnica de simulao que quando ela precisar
ser substituda por uma estratgia real, algum retrabalho necessrio.
Uma terceira alternativa manter a classificao obtida e utilizar uma estratgia de
simulao da persistncia no incio e depois substitui-la pelo FT quando os casos de uso
gerenciadores de dados forem desenvolvidos. Entretanto, cuidado adicional deve ser tomado
porque o FT de persistncia impe certas restries de projeto que precisam ser levadas em
conta desde o incio da elaborao do modelo de projeto. Se essas restries forem
negligenciadas, o acoplamento
21
do FT de persistncia com o sistema pode ser dificultado,
exigindo mudanas significativas de projeto.

20
Dentro do contexto desta tese, um caso de uso gerenciador de dados um caso de uso que manipula
funcionalidades de persistncia, como incluso, alterao e remoo.
21
O termo acoplamento est sendo usado neste trabalho em um sentido mais amplo do que composio. O
processo de reso de um FT possui as etapas de instanciao e composio. Quando se diz que o FT ser
acoplado parte base da aplicao, assume-se que as duas etapas citadas devem ser realizadas. Assim, o termo
acoplamento torna-se sinnimo de processo de reso.
Captulo 6 ProFT/PU
141
Assim, se a opo for por deslocar os casos de uso gerenciadores de dados para
posies superiores da classificao deve-se identificar casos de uso que possuem
dependncia com conceitos persistentes. Para a identificao dos conceitos persistentes, cada
caso de uso da classificao obtida deve ser analisado com vistas a identificar quais so os
conceitos que ele provavelmente utiliza para cumprir suas responsabilidades. Por exemplo, o
caso de uso Fazer Reserva mostrado na Figura 6.5 possui, destacado em negrito, alguns
conceitos que provavelmente so persistentes, como reserva, hotel, acomodao, tipo de
acomodao e cliente. Os casos de uso gerenciadores de dados desses conceitos devem ser
movidos para posies mais altas da classificao em relao ao caso de uso Fazer Reserva.
Figura 6.5 Caso de Uso Hipottico Fazer Reserva
Note-se que os casos de uso gerenciadores de dados que devem ser movidos para as
posies iniciais so apenas os que manipulam conceitos que sero utilizados pelos casos de
uso em anlise. No se deve mover todos os casos de uso gerenciadores de dados para as
posies iniciais da lista de uma nica vez porque isso pode gerar trabalhos desnecessrio nas
primeiras iteraes.
Depois que uma classificao mais realista for obtida, deve-se planejar quantas
iteraes devem ser realizadas e quais casos de uso devem ser trabalhados em cada iterao.
Como o levantamento de requisitos feito at o momento no est completo, novos casos de
uso podem surgir durante as iteraes, havendo a necessidade de modificao no
planejamento das iteraes seguintes. Lidar com essas modificaes uma particularidade do
PU, pois o plano adaptativo e no congelado de modo especulativo logo no incio do
projeto. Dessa forma, o engenheiro de software deve despender mais esforo no planejamento
da prxima iterao, e no se preocupar muito com as iteraes posteriores, j que podem ser
bastante influenciados pelas descobertas feitas na iterao anterior.
O critrio sugerido para a identificao do nmero de iteraes o prazo estipulado
para o trmino. Considerando hipoteticamente que um sistema tenha que ser desenvolvido
Caso de Uso: Fazer Reserva

Cenrio de Sucesso Principal

1. O Operador de Reservas solicita fazer uma reserva.
2. O Operador de Reservas escolhe, em ordem, o hotel, datas de incio e fim da reserva, e tipo de acomodao.
3. O sistema verifica se h acomodao disponvel no perodo especificado no hotel especificado.
4. O Sistema fornece disponibilidade e o preo ao Operador da Reserva.
5. O Operador de Reservas solicita ao sistema a operao de fazer reserva.
6. O Operador de Reservas fornece ao sistema o nome e dados para contato do cliente.
7. O Operador de Reservas fornece ao sistema o e-mail de contato.
8. O Sistema registra a reserva e aloca um cdigo para a reserva efetuada.
9. O Sistema mostra o cdigo da reserva para o Operador da Reserva.
10. O Sistema cria e envia os dados de confirmao da reserva por e-mail para o cliente.
Captulo 6 ProFT/PU

142
em um perodo mximo de seis meses, pode-se estipular quatro iteraes de um ms e meio
cada, que um nmero sugerido pelo PU. A distribuio dos casos de uso em cada iterao
deve ser feita pelos critrios de tamanho e importncia dos casos de uso.
Na Tabela 6.6 mostrado um modelo que pode ser utilizado para a classificao dos
casos de uso e planejamento das iteraes.
Tabela 6.6 Modelo de Tabela para Classificao de Casos de Uso e Planejamento de Iteraes

Um dos artefatos que deve ser desenvolvido quando o ProFT/PU utilizado a viso
de iterao. Esse artefato consiste em um diagrama de casos de uso que mostra apenas os
casos de uso alocados para a iterao atual. O objetivo auxiliar a equipe de desenvolvimento
a acompanhar a evoluo do sistema com base nos casos de uso que so adicionados em cada
iterao. Esse diagrama de casos de uso constantemente evoludo conforme o processo
progride, at que o sistema todo esteja modelado.
Est sendo considerado no contexto deste trabalho que cada iterao possui acesso a
trs tipos de casos de uso: 1) os casos de uso funcionais originalmente alocados para a
iterao; 2) os casos de uso no-funcionais que se relacionam com os casos de uso
originalmente alocados e 3) a todos os casos de uso, implementados ou no, das iteraes
anteriores. Assim, quando os casos de uso originalmente alocados para a iterao so trazidos
para o ambiente de desenvolvimento, todos os outros citados tambm os acompanham.
Os casos de uso originalmente alocados para a iterao so denominados de
originais e os que aparecem na viso porque so no-funcionais relacionados aos originais
so denominados de apoiadores. Recebem esse nome porque geralmente apiam de alguma
forma a funcionalidade dos originais. A iterao atual s no possui acesso aos casos de uso
alocados para as iteraes seguintes.
6.4 IASL DL LLABORAO
A fase de elaborao se concentra no projeto e na implementao dos casos de uso alocados
para a iterao atual e realizada em iteraes. Os casos de uso originais devem ser obtidos
Iterao Classificao Caso de Uso
1 Caso de Uso 1 1 Iterao
2 Caso de Uso 2
7 Caso de Uso 4
11 Caso de Uso 6
Captulo 6 ProFT/PU
143
na viso de iterao. O objetivo principal implementar uma poro do sistema que esclarea
os detalhes arquiteturais e de maior risco.
As primeiras iteraes da elaborao possuem grande nfase nos requisitos e na
anlise, j que muitos requisitos ainda no foram descobertos e registrados. Entretanto, com o
decorrer das iteraes, a nfase deixa de ser nos requisitos e passa a ser na anlise, no projeto
e na implementao.
Embora as atividades das fases de elaborao e construo estejam sendo mostradas
de forma seqencial neste captulo, o leitor deve estar atento ao fato de que elas podem se
repetir vrias vezes, dependendo da quantidade de iteraes planejadas para o
desenvolvimento. Assim, durante a leitura de uma determinada atividade, deve-se estar ciente
de que ela pode ser executada sobre uma parte j desenvolvida do sistema, no caso de no ser
a primeira iterao. Nesse caso, os artefatos gerados por ela so simplesmente atualizados e
no so gerados novamente.
Nas sees seguintes so mostradas as trs disciplinas que possuem mais nfase dentro
desta fase: Anlise, Projeto e Implementao.
6.4.J Disciplina Anlise
Nesta disciplina o objetivo refinar os casos de uso alocados para a iterao atual, descobrir
novos requisitos e elaborar o modelo de domnio (ou modelo conceitual). Com o andamento
das iteraes, o trabalho diminui nesta disciplina e a nfase passa a ser maior na disciplina de
projeto e implementao.
Na Figura 6.6 so mostradas as atividades desta disciplina no formato SADT (Ross,
1977). Apenas a atividade Identificar e Registrar Casos de Uso Candidatos a Aspectos
particular do ProFT/PU. Cada uma dessas atividades detalhada nas subsees seguintes.
6.4.J.J Identificar e Registrar Casos de Uso Colaboradores
O objetivo nesta atividade identificar casos de uso de nvel mais baixo, os quais no so
facilmente identificveis por inspeo do documento de requisitos. Deve-se analisar a
descrio dos casos de uso escolhidos para esta iterao e identificar trechos
22
que so
funcionalidades que meream ser transformadas em novos casos de uso. Essa atividade
tambm conhecida como fatorao de casos de uso.
De acordo com a terminologia definida neste processo, quando um trecho de um caso
de uso transformado em um novo caso de uso, diz-se que o caso de uso que j existia o
criador e o novo caso de uso o colaborador. O novo caso de uso tem esse nome porque

22
Um trecho de um caso de uso pode ser uma nica linha ou um conjunto de linhas que descrevem um
determinado comportamento.
Captulo 6 ProFT/PU

144
colabora para a realizao dos requisitos do caso de uso criador, j que ele na verdade parte
do caso de uso criador. Esses papis que os casos de uso podem assumir so especficos de
cada relacionamento, isto , um caso de uso C pode ter o papel de criador no relacionamento
que mantm com o caso de uso B e de colaborador no relacionamento que mantm com o
caso de uso D, por exemplo. Isso ocorre quando um caso de uso colaborador novamente
analisado e um de seus passos transformado em um novo caso de uso.

Figura 6.6 Atividades da Fase de Elaborao
A fatorao de casos de uso realizada nesta atividade tem como um de seus objetivos
facilitar a identificao de interesses transversais em outras atividades do processo. Como os
interesses transversais so funcionalidades que geralmente atuam em pontos especficos de
um outro comportamento, a fatorao de casos de uso pode auxiliar na identificao de casos
de uso que ocorrem como parte do comportamento de outros casos de uso, caracterizando
interesses transversais. Outro objetivo desta fase alcanar um bom nvel de modularizao
do sistema. Mesmo se os casos de uso colaboradores identificados no forem interesses
transversais, a fatorao realizada resulta em uma arquitetura mais legvel e compreensvel.
Algumas perguntas que auxiliam a descobrir se um trecho de um caso de uso merece
ser transformado em um novo caso de uso colaborador podem ser vistas no Modelo de
Deciso apresentado na Tabela 6.7, que uma ferramenta conceitual particular desta
atividade.
A pergunta nmero 1 auxilia na identificao de funcionalidades que so
compartilhadas por dois ou mais casos de uso. Os casos de uso que podem ser analisados so
os que esto presentes na viso de iterao. Se a resposta para essa pergunta for sim, no h
Disciplina Anlise
Identificar e
Registrar Casos
de Uso
Colaboradores
Doc.
Requisitos
Interessados
no sistema
Desenvolver
Modelo
Conceitual
Definir
Contratos para
as Operaes
do Sistema
Criar Diagramas
de Seqncia do
Sistema
TCCaU-R Atualizada
Novos Casos de Uso
Tabela de Candidatos a Aspectos
Diagrama de
Casos de Uso
Diagramas de Seqncia do Sistema
Modelo Conceitual
Contratos
Identificar e
Registrar Casos
de Uso
Candidatos a
Aspectos
N
M
Captulo 6 ProFT/PU
145
necessidade de continuar o processo de deciso, pois somente isso j justifica a transformao
do trecho em um novo caso de uso. Normalmente, o tipo de relacionamento que deve ser
criado neste caso de incluso ou de extenso. No comum que relacionamentos de
restrio sejam identificados com esse critrio.
Tabela 6.7 Tabela de Deciso para Identificao de Novos Casos de Uso
No. Pergunta Resposta Deciso
(Deve Fatorar?)
Sim Sim 1 A funcionalidade descrita pelo trecho utilizada pelos outros
casos de uso disponveis na viso de iterao? No Pergunta 2
Sim No 2 A funcionalidade descrita pelo trecho essencial para o
comportamento do caso de uso? No Sim

A pergunta nmero 2 auxilia na identificao de trechos cuja funcionalidade no
essencial ao comportamento do caso de uso, isto , o objetivo principal do caso de uso pode
ser alcanado mesmo se o trecho for removido. Uma diretriz imaginar o caso de uso sem
aquele passo; se mesmo assim seu comportamento faz sentido, pode ser que ele merea ser
transformado em um novo caso de uso. O tipo mais comum de relacionamento nesta situao
o de extenso, pois geralmente a funcionalidade encontrada alguma poltica que estende o
comportamento do caso de uso base.
A utilizao da tabela de deciso deve ser vista apenas como um auxlio ao processo
de deciso, e no como uma obrigatoriedade do processo descrito. A experincia do
engenheiro de software e o conhecimento no domnio so outros fatores que devem ser
levados em conta durante a deciso.
A pergunta nmero 1 do modelo de deciso exige que os casos de uso funcionais
sejam comparados aos pares, isto , elege-se um determinado caso de uso e prossegue-se com
a pergunta para os demais. Sugere-se montar uma matriz como o modelo mostrado pela
Tabela 6.8. A diagonal principal da matriz delimita as comparaes que j foram realizadas.
Deve-se colocar a letra n quando no h trechos com funcionalidades comuns entre os
dois casos de uso, e s quando h. A existncia de trecho de funcionalidade comum entre
dois casos de uso motivo para fator-lo, no sendo necessrio prosseguir com o processo de
deciso. Entretanto, a segunda pergunta auxilia a identificar se o relacionamento entre o caso
de uso base e o colaborador de incluso ou de extenso.
Observe-se que como o processo descrito aqui iterativo e incremental, nas iteraes
futuras os casos de uso alocados para a iterao sero comparados com todos os outros das
iteraes anteriores, e no apenas entre si. Assim, pode ser que uma determinada
funcionalidade comum entre um caso de uso alocado para a iterao atual e um que j foi
Captulo 6 ProFT/PU

146
implementado j tenha sido fatorada em um novo caso de uso, fazendo surgir apenas um novo
relacionamento entre os casos de uso e no um novo caso de uso colaborador.
Tabela 6.8 Modelo de Matriz de Comparao de Casos de Uso para a Pergunta 1
Pergunta 1 H trecho com funcionalidade compartilhada pelos outros casos de uso?
Caso de Uso 1 Caso de Uso 2 Caso de Uso 3 Caso de Uso 4 Caso de Uso 5
Caso de Uso 1 - n n n s
Caso de Uso 2 - - s n n
Caso de Uso 3 - - - s n
Caso de Uso 4 - - - - n
Caso de Uso 5 - - - - -

Depois que novos casos de uso foram identificados, deve-se atualizar a Tabela de
Correspondncia Caso de Uso/Requisitos com os novos casos de uso. Esses novos casos de
uso identificados tambm devem ser acrescentados na viso de iterao.
6.4.J.2 Identificar e Registrar Casos de Uso Candidatos a Aspectos
Esta atividade particular do ProFT/PU e o objetivo identificar casos de uso que apresentam
indcios de que sua implementao com aspectos factvel. Esses casos de uso so
denominados candidatos a aspectos, porque no h certeza se essa tecnologia deve ser
usada em sua implementao. A deciso final sobre a utilizao da tecnologia ser feita
durante a disciplina de projeto.
Quatro critrios devem ser utilizados para identificar os casos de uso que so
candidatos a aspectos: quantidade de relacionamentos, tipo do caso de uso, extenso e
essencialidade. O critrio da quantidade de relacionamentos seleciona casos de uso que
possuem relacionamento com mais de um caso de uso. Em analogia ao problema do
espalhamento de cdigo, provavelmente a implementao desses casos de uso possuir
trechos de cdigo relacionados a sua funcionalidade espalhados por vrios locais do sistema.
So aqueles que so includos por dois ou mais casos de uso (relacionamento <<include>>),
que estendem dois ou mais casos de uso (relacionamento <<extend>>) ou que restringem dois
ou mais casos de uso (relacionamento <<constrain>>).
O critrio da quantidade de relacionamentos deve ser utilizado com cautela, pois em
um processo iterativo e incremental como este, a quantidade de relacionamentos de um caso
de uso em uma iterao pode ser muito diferente da quantidade real que ele possuir no final
do desenvolvimento. Assim, uma situao que pode ocorrer justamente no selecionar um
caso de uso que um bom candidato a aspecto porque ele possui apenas um relacionamento,
implement-lo com tcnicas tradicionais, e s perceber que ele adequado para ser
implementado como aspecto nas iteraes posteriores. Essa uma particularidade de um
processo iterativo e incremental, pois a viso de todo o sistema s ser possvel depois que a
maioria das iteraes estiver concluda. Em processos seqenciais, em que a anlise e o
Captulo 6 ProFT/PU
147
projeto so realizados completamente antes de passar para a implementao, o critrio da
quantidade de relacionamentos pode ter um peso maior. Por isso, sugere-se que este critrio
tenha um peso menor do que os demais no processo de deciso.
O critrio do tipo seleciona casos de uso do tipo no-funcional, isto , aqueles que
possuem esteretipo <<NF>>. Essa identificao facilitada porque a atividade Identificar e
Especificar Casos de Uso no-Funcionais que ocorreu na fase de concepo, j identificou
alguns casos de uso no-funcionais. Assim, basta verificar se os casos de uso alvo desta
iterao se encontram no artefato Tabela de Interesses Transversais No-Funcionais.
O terceiro seleciona casos de uso que se relacionam por extenso (<<extend>>) com
um ou mais casos de uso. Como o comportamento dos casos de uso de extenso so
funcionalidades extras que so adicionadas ao comportamento de um caso de uso base, podem
tratar de funcionalidades adequadas para serem implementadas como aspectos. Este critrio
pode, aparentemente de forma errada, selecionar casos de uso que possuem apenas um
relacionamento de extenso, entretanto h quatro justificativas para realizar essa seleo:
1. Pode ocorrer que novos relacionamentos apaream nas outras iteraes. Como
cada iterao adiciona casos de uso sobre a iterao anterior, um caso de uso pode
possuir apenas um relacionamento nesta iterao porque os outros casos de uso
que ele estende ainda no esto presentes, isto , sero tratados nas prximas
iteraes;
2. Pode existir um FT para implementar o caso de uso. Mesmo se depois de todas as
iteraes o caso de uso permanecer com apenas um relacionamento, mas existir
um FT que possa ser utilizado para implement-lo, pode ser conveniente usar a
tecnologia de aspectos pela facilidade de implementao fornecida pelo
framework;
3. Pode ser que o caso de uso colaborador encapsule um requisito voltil. Em
conseqncia de grande possibilidade de modificao, requisitos volteis so
adequados para serem implementados com aspectos, independentemente do seu
grau de ocorrncia dentro do sistema.
4. Pode ser que o caso de uso encapsule um interesse que uma caracterstica de um
FT j existente. Implementando-o tambm como um FT, uma nova caracterstica
pode ser adicionada na linha de produtos permitindo, que novos membros da linha
sejam criados.

Captulo 6 ProFT/PU

148
O critrio da essencialidade visa a identificar se o comportamento do caso de uso colaborador
essencial ao comportamento genrico do caso de uso base, ou se apenas uma adio de
funcionalidade que exclusiva do sistema que est sendo desenvolvido. Relacionamentos de
extenso geralmente se enquadram nessa situao. Por exemplo, um dos sistemas que foi
desenvolvido no contexto desta tese realiza o controle de reservas de um hotel. Esse sistema
possui um caso de uso de uso responsvel pelo clculo de descontos para clientes que
possuem convnio com determinadas empresas. Se a anlise se restringir ao sistema em
questo, essa funcionalidade essencial, pois os requisitos do sistema deixam claro que ela
deve existir. Contudo, sabe-se que podem existir sistemas de reservas que no possuem
descontos para empresas conveniadas. Dessa forma, a funcionalidade de clculo de descontos
essencial ao sistema de reserva, mas no essencial funcionalidade geral de realizao de
reservas, pois uma reserva pode ter seu preo calculado sem qualquer tipo de desconto.
Um contra-exemplo o caso de uso Verificar Disponibilidade de Acomodao,
tambm pertencente ao sistema de reservas desenvolvido. Esse caso de uso includo por trs
outros e consiste em verificar se existe acomodao disponvel no hotel no perodo desejado
pelo cliente. Essa funcionalidade considerada parte integrante do caso de uso Fazer Reserva,
pois dificilmente haver um sistema de reservas que no verifique as acomodaes
disponveis antes de efetuar uma reserva. O uso restrito deste critrio pode muitas vezes
selecionar relatrios e consultas como candidatos a aspectos, mas, em princpio, no devem
ser considerados.
Ressalta-se que os quatro critrios so independentes, isto , um no influencia o
outro, basta que um seja satisfeito para que o caso de uso seja considerado candidato a
aspecto. Os casos de uso identificados como candidatos devem ser listados em uma tabela
denominada Tabela de Candidatos a Aspectos, cujo modelo pode ser visto na Tabela 6.9. Na
primeira coluna colocado o nome do caso de uso, na segunda seu tipo (se funcional ou
no-funcional), e na terceira o critrio utilizado. A quarta coluna reservada para atualizaes
que ocorrero nas prximas iteraes. Caso algum caso de uso selecionado venha a ser
implementado com aspectos, a caixa da coluna implementado deve ser marcada com um
X. A anlise deve se restringir aos casos de uso que podem ser acessados na iterao, os
quais podem ser vistos na viso de iterao.
Tabela 6.9 Modelo para Tabela de Candidatos a Aspectos

Caso de Uso Tipo (F/NF) Critrio Implementado

Captulo 6 ProFT/PU
149
Algo importante a ser observado que esta atividade apenas um apoio para a
identificao de casos de uso que podem ser implementados como aspectos. No significa que
outros casos de uso candidatos no possam ser descobertos durante a realizao de outras
atividades. Por exemplo, durante a elaborao dos diagramas de interao na disciplina de
projeto, o comportamento do caso de uso projetado com detalhes de implementao, o que
pode auxiliar na descoberta de requisitos volteis, os quais talvez sejam adequados para serem
implementados como aspectos. Outro ponto do processo em que podem surgir novos aspectos
de granularidade mais fina durante o processo de reso do FT. Isso ocorre porque durante
esse processo que se pode constatar a carncia de uma nova variabilidade ou caracterstica,
fazendo com que o projeto e implementao dessa nova caracterstica possam ser feitos como
um novo FT.
A adio de novos casos de uso na Tabela de Candidatos a Aspectos a situao mais
convencional desta atividade. Entretanto, a reavaliao dos critrios tambm deve ser feita
porque muitas vezes um critrio que levou seleo de um caso de uso em uma iterao pode
no ser mais vlido em iteraes subseqentes. Isso geralmente ocorre em conseqncia do
aparecimento de novos casos de uso. A situao mais comum um caso de uso que foi
selecionado por meio do critrio um relacionamento de extenso em uma iterao, ter seu
critrio alterado para quantidade de relacionamentos, por causa do aparecimento de novos
relacionamentos de extenso ou incluso.
6.4.J.3 - Criar Diagramas de Seqncia do Sistema
O objetivo nesta atividade criar um diagrama de seqncia do sistema (DSS) para cada caso
de uso ou cenrio que est sendo tratado nesta iterao. Esses diagramas representam o
comportamento do sistema em resposta a eventos gerados por entidades externas e auxiliam a
identificar as principais operaes do sistema.
As operaes de sistema que so casos de uso candidatos a aspectos devem ser
representadas normalmente nos DSS, mesmo sem saber a tcnica de implementao que ser
utilizada para elas. Como um DSS no uma representao de software, e sim um modelo
comportamental, no importa como as operaes de sistema sero implementadas, pois elas
ocorrero da mesma forma, e possivelmente, na mesma ordem.
6.4.J.4 Desenvolver Modelo Conceitual
Da mesma forma que a atividade anterior, a criao do modelo conceitual deve se concentrar
apenas nos casos de uso que esto sendo tratados nesta iterao. Para a elaborao desse
modelo deve-se analisar os casos de uso que esto sendo trabalhados nesta iterao, em busca
de conceitos do domnio.
Captulo 6 ProFT/PU

150
Durante a elaborao do modelo conceitual, os conceitos que forem oriundos de casos
de uso candidatos a aspectos devem ser marcados com uma nota, informando que so
conceitos candidatos a aspectos. Isso deve ser feito para rastrear esses conceitos at a
disciplina de projeto, onde podem ou no se transformar em classes de software e,
conseqentemente, podem introduzir relacionamentos indesejados na arquitetura do sistema.
Se eles forem considerados como aspectos na disciplina de projeto, devero ser projetados e
implementados como aspectos, para que no influenciem na parte base da aplicao.
6.4.J.S Definir Contratos das Operaes do Sistema
Nesta atividade o objetivo descrever com mais detalhes as operaes mais complexas de
sistema. Com essa descrio pode ser possvel identificar comportamentos que ocorrem como
pr e ps-condies e que talvez possam ser implementadas com aspectos. Em muitos casos,
as pr-condies podem ser implementadas como adendos tipo before(), enquanto que as
ps-condies como adendos do tipo after().
6.4.2 Disciplina Projeto
O objetivo nesta disciplina criar um modelo de classes de projeto, modelos de interao, e
quaisquer outros modelos que auxiliem a documentar e registrar o comportamento e a
estrutura do sistema. Nesta atividade tambm podem ser identificados e projetados alguns
aspectos do sistema.
Na Figura 6.7 so mostradas as atividades desta disciplina e suas interdependncias.
As atividades que no so particulares do ProFT/PU so Desenvolver Diagramas de Interao,
Desenvolver Modelo de Classes de Projeto e Desenvolver Modelo de Dados. Na figura
mostrado que h dois caminhos que podem ser realizados paralelamente ou sinergicamente.
No caminho que se inicia do lado esquerdo da figura encontram-se atividades especficas para
a identificao, projeto e acoplamento dos aspectos com o cdigo-base. Do lado direito
encontram-se algumas atividades convencionais de qualquer processo de desenvolvimento,
que so atividades para elaborao de diagramas de interao e de classes.
Procura-se mostrar que no h uma seqncia obrigatria de execuo entre esses
caminhos. Por exemplo, a atividade Identificar Aspectos pode ser iniciada logo que a iterao
comear ou durante a execuo das atividades de desenvolvimento dos diagramas de iterao
ou diagramas de classe de projeto, como esta sendo mostrado pelas setas com espaamento
mais distante, que partem dessas atividades em direo atividade Identificar Aspectos. Isso
destaca uma propriedade importante da orientao a aspectos que cita que aspectos so
propriedades emergentes que podem surgir durante o decorrer das atividades do
desenvolvimento do sistema.
Captulo 6 ProFT/PU
151
A atividade Projetar Acoplamento dos Aspectos com a Base pode ser realizada sempre
que um aspecto foi selecionado para a iterao atual e projetado. Note-se que essa atividade
s pode ser realizada se houver um modelo de classes da parte base do sistema. Quando o
processo se encontra em sua primeira iterao, a atividade Desenvolver Modelo de Classes de
Projeto deve, obrigatoriamente, ser realizada antes da atividade Projetar Acoplamento dos
Aspectos com a Base. Mas o mesmo no ocorre nas iteraes seguintes, pois um aspecto pode
ser identificado e projetado com o modelo de classes oriundo da iterao anterior.

Figura 6.7 Atividades da Disciplina Projeto
A atividade Atualizar Regras de Composio est sendo representada por um
retngulo com cantos arredondados para destacar que uma atividade opcional. Ela deve ser
realizada somente se o desenvolvimento do diagrama de classes da iterao atual incluir
alguma classe, mtodo ou atributo que deve ser afetado pelos aspectos que j se encontram
acoplados ao sistema.
Identificar
Aspectos
Selecionar
Aspectos para
a Iterao Atual
Disciplina Projeto
Tabela de Aspectos
Tabela de Acompanhamento da
Implementao
dos Aspectos
Modelo de Projeto do
Aspecto (Tema)
Projetar
Aspectos
Desenvolver Modelo de
Projeto Composto
Desenvolver Viso da
Arquitetura
Modelo de Projeto
Combinado
Modelo de Projeto
Composto
Viso da Arquitetura
Registro de Pontos
de Juno Registrar Pontos de
Juno
Modelo de Classes
de Projeto
Modelo de Projeto
Combinado Atualizado
Diagramas de Interao
Desenvolver
Modelo de
Dados
Desenvolver
Modelo de
Classes de
Projeto
Casos
de Uso
Tabela de
Candidatos
a Aspectos
Desenvolver
Diagramas de
Interao
Modelo de Classes
Projetar Acoplamento dos
Aspectos com a Base
Atualizar Regras
de Composio
N
N
N
N
N
N
N
N
Captulo 6 ProFT/PU

152
As trs ltimas atividades devem ser realizadas sempre que um determinado aspecto
acoplado com a parte base do sistema ou as regras de composio so atualizadas. Essas
atividades geram artefatos importantes que auxiliam no acompanhamento e na viso geral do
prosseguimento do processo.
Os artefatos gerados por cada uma das atividades so constantemente atualizados
conforme as iteraes so realizadas. As atividades mostradas na Figura 6.7 so descritas com
mais detalhes nas prximas subsees.
6.4.2.J - Identificar Aspectos
O objetivo nesta atividade identificar quais dos casos de uso candidatos a aspectos, listados
na Tabela de Candidatos a Aspectos devem ser implementados com a tecnologia de aspectos.
Os artefatos utilizados para essa tomada de deciso so o modelo de casos de uso da iterao
atual, a descrio dos casos de uso, o documento de requisitos e, se necessrio, diagramas de
interao. Note-se que a identificao de que um caso de uso deve ser implementado com
aspectos no significa que isso ser feito na iterao atual, a deciso sobre a iterao em que
ele ser implementado tomada durante a prxima atividade.
Para identificar se um caso de uso candidato a aspecto realmente deve ser
implementado com tal paradigma, os critrios mostrados na Tabela 6.10 devem ser utilizados.
O primeiro critrio consiste em averiguar se o caso de uso trata de um requisito no-funcional
que um exemplo clssico de aspecto relatado na literatura. A Tabela 6.11 exibe uma lista
no exaustiva de requisitos no-funcionais clssicos da literatura que so adequados para
serem implementados como aspectos. Em caso afirmativo, a sugesto que o caso de uso seja
implementado com aspectos, mas a deciso final ainda pode ser influenciada por outros
fatores, como, por exemplo: a existncia de um framework orientado a objetos para a
implementao do requisito o que consumiria menos tempo do que implement-lo do zero
com aspectos; a habilidade que a equipe de desenvolvimento possui com orientao a
aspectos; o risco que um paradigma ainda recente pode trazer, etc.
Em geral, os casos de uso no-funcionais devem ser implementados como aspectos
pelos seguintes motivos:
No fazem parte da funcionalidade bsica do sistema e interessante que sejam
implementados em mdulos separados e independentes da aplicao bsica;
Geralmente so recorrentes em muitas aplicaes e possuem caractersticas
comuns, o que possibilita a generalizao e maior facilidade de reso;
Captulo 6 ProFT/PU
153
A separao da implementao no-funcional da funcional permite que as
funcionalidades bsicas do sistema sejam testadas independentemente, ou em
conjunto com a parte no-funcional.
Tabela 6.10 Critrios para Identificao de Aspectos
No Critrios Descrio Pergunta
1 NF clssico Procura identificar se o caso de uso
transversal um exemplo clssico de
aspecto no-funcional relatado na literatura
O caso de uso transversal um aspecto
clssico da literatura?
2 Atomicidade Procura fazer comparaes aos pares entre
casos de uso com o objetivo de averiguar se
o compartilhamento fruto de um requisito
transversal ou simplesmente um requisito
mal redigido.
O caso de uso transversal atmico?
3 Volatilidade Procura identificar se o caso de uso envolve
um requisito voltil, isto , requisitos que
possuem uma alta probabilidade de
mudana.
O comportamento do caso de uso transversal
voltil?
4 Framework
Transversal
Identifica se h um FT disponvel que possa
ser utilizado para a implementao do caso
de uso.
H um FT que pode ser utilizado para a
implementao do caso de uso?
Tabela 6.11 Lista de Requisitos No-Funcionais Clssicos
Persistncia
Autenticao
Controle de acesso
Registro de acesso
Rastreamento
Memria Auxiliar
Repositrio de Conexes
Distribuio
Concorrncia
Tratamento de excees
Criptografia
Depurao de Programs
Garantia de polticas
Padres de projeto
Tratamento de erros (excees)
Regras de Negcio

O segundo critrio, que oriundo do trabalho de Clarke e Baniassad (2005), s pode
ser aplicado para os casos de uso que possuem mais de um relacionamento com outros casos
de uso. O objetivo averiguar se o caso de uso atmico ou no, isto , se ele manipula
apenas uma funcionalidade. Isso deve ser feito porque os requisitos numerados do documento
de requisitos podem envolvem, erroneamente, mais de uma funcionalidade, gerando casos de
uso que tambm tratam de mais de uma funcionalidade. Assim, esses casos de uso acabam
sendo compartilhados por outros casos de uso porque tratam de mais de uma funcionalidade e
no porque tratam de requisitos transversais.
Por exemplo, na Figura 6.8 mostrado hipoteticamente um caso de uso colaborador
que estende o comportamento de dois casos de uso base, isto , o caso de uso colaborador
Captulo 6 ProFT/PU

154
compartilhado pelos casos de uso base. Como os casos de uso so gerados a partir dos
requisitos do documento de requisitos, o compartilhamento existente pode ser oriundo de um
requisito que envolva duas funcionalidades, fazendo com que cada caso de uso base utilize
uma das funcionalidades. O critrio de atomicidade tem como objetivo verificar se o requisito
que originou o caso de uso colaborador no pode ser dividido, para a eliminar o
compartilhamento. Nesse sentido, a Tabela de Correspondncia Caso de Uso/Requisitos deve
ser analisada com o objetivo de verificar qual foi o requisito numerado originador do caso de
uso transversal. Deve-se tentar dividir a sentena textual originadora do requisito para
eliminar o compartilhamento.
Outra forma de realizar essa verificao analisar a prpria descrio do caso de uso.
Quando o relacionamento entre eles de extenso, o caso de uso colaborador possui uma
seo especfica chamada fluxo de extenso, que descreve tanto o comportamento que deve
ser inserido quanto o ponto de extenso no caso de uso base onde o comportamento ser
inserido. Considerando a Figura 6.8, se o comportamento inserido nos caso de uso base forem
diferentes, ento o caso de uso colaborador pode ser divido em dois, em que cada um trate de
um dos comportamentos, eliminando assim, o compartilhamento. A impossibilidade de
eliminar o compartilhamento um indcio de que o comportamento descrito pelo caso de uso
transversal, e talvez possa ser implementado como aspectos.
O critrio de volatilidade consiste em averiguar se o requisito tratado pelo caso de uso
colaborador voltil. Um requisito voltil representa regras de negcio que os interessados no
sistema desejam mudar rapidamente, a qualquer hora, dependendo das demandas de mercado.
Exemplos de requisitos volteis so: se o valor das movimentaes financeiras de
determinado cliente durante o ano for superior a quinhentos mil dlares, ele receber um
prmio, ou Os dez clientes que mais gastaram na loja durante a semana ganharo cinco
por cento de desconto na prxima compra. Os valores das regras de negcio, como os
quinhentos mil dlares e o valor da porcentagem de desconto dos clientes da loja, e as
prprias estratgias de clculo so muito suscetveis a situaes do mercado e polticas
organizacionais, podendo mudar a qualquer momento.

Figura 6.8 Exemplo Hipottico de Caso de Uso Transversal

Caso de Uso Base 1
Caso de Uso Transversal
Caso de Uso Base 2
<<extend>>
<<extend>>
Captulo 6 ProFT/PU
155
Quando requisitos volteis so implementados com tcnicas tradicionais de
programao, geralmente tornam-se fixos dentro do sistema, dificultando modificaes
futuras, que s podem ser feitas recompilando o sistema todo, ou parte dele. Alm disso,
tambm comum aparecer dependncias estruturais da parte base para a parte voltil, por
exemplo, uma classe da parte base com um relacionamento de associao com uma classe da
parte voltil. Isso implica na adio de um atributo, do tipo da classe voltil, na classe-base, e
em uma srie de outras modificaes, como por exemplo: o construtor da classe-base deve ser
alterado para considerar o novo atributo, dois novos mtodos de acesso devem ser criados, um
set e um get, e as operaes de interface agora tambm devem considerar o novo atributo.
Quando essas dependncias estruturais ocorrem da parte base para a parte voltil,
sugere-se que o atributo que representa o relacionamento seja introduzido na classe-base por
meio de algum mecanismo de declaraes intertipo, como, por exemplo, aquele existente na
linguagem AspectJ. Segundo Moreira e Arajo (2004), a implementao de requisitos volteis
com aspectos uma estratgia interessante porque facilita a incluso/remoo/alterao
desses requisitos depois que o sistema estiver pronto.
Para descobrir se um caso de uso envolve um requisito voltil, deve-se analisar a
descrio do caso de uso, ou dos casos de uso, e buscar por regras de negcio com tendncia
de mudanas. Geralmente esse tipo de requisito possui uma parte estvel, que genrica e
aplicvel a vrios sistemas de um domnio, e uma parte varivel, que especfica do sistema
que est sendo desenvolvido. Um caso de uso que calcula descontos, por exemplo, envolve
um requisito voltil, pois os valores e as estratgias de descontos podem variar de sistema
para sistema. Por exemplo: pode haver descontos que so feitos em porcentagens, descontos
de valores fixos, descontos promocionais de fim de semana ou de algum perodo festivo do
ano. Caso a descrio do caso de uso no apresente detalhes suficientes para a deciso, deve-
se buscar informaes mais detalhadas em outras fontes para que a deciso possa ser tomada
com mais certeza. Uma alternativa a elaborao de diagramas de interao para o caso de
uso. Como esses diagramas representam unidades de software, sua elaborao detalha as
operaes e mtodos necessrios para a realizao do caso de uso.
Como comentado anteriormente, casos de uso que envolvem requisitos volteis podem
surgir durante a realizao de outras atividades de projeto em conseqncia do nvel de
detalhes obtido. O critrio da volatilidade apresentado aqui deve ser aplicado aos casos de uso
listados na Tabela de Candidatos a Aspectos, mas tambm deve servir como diretriz para a
identificao de novos requisitos volteis durante outras atividades do processo.
Captulo 6 ProFT/PU

156
O ltimo critrio Framework Transversal procura identificar se h um FT que
possa ser utilizado na implementao do caso de uso. Esse critrio importante e pode ser
decisivo na opo de implementar o caso de uso com aspectos. A ausncia de um FT pode
inviabilizar a implementao de um interesse que transversal por causa da dificuldade que
um novo paradigma traz para a equipe de desenvolvimento. J a existncia de um FT tambm
pode ser um fator decisivo em se implementar com aspectos, mesmo se o caso de uso no
satisfizer a todos os critrios que o qualificam como aspecto.
O processo para identificar se h um FT que pode ser usado na implementao de um
caso de uso consiste em dois passos. O primeiro consultar o repositrio disponvel
biblioteca ou famlia de FTs com o objetivo de identificar um FT que implementa o
interesse tratado pelo caso de uso. Essa identificao pode ser feita pelo nome do FT; por
exemplo, se o caso de uso trata do interesse de Autenticao, deve-se localizar um FT que
possua esse nome. Embora parea simples, a quantidade de FTs disponveis e a utilizao de
vrios termos que representam um mesmo interesse podem dificultar a busca. O interesse de
controle de acesso, por exemplo, tambm referenciado na literatura como Autorizao
(Zhang et al., 2004). Mesmo assim, a busca por FTs que implementam interesses transversais
no-funcionais facilitada, pois no h muita variao.
Entretanto, a busca por FTs que implementam interesses transversais funcionais torna-
se um pouco mais complicada porque o FT pode no possuir um nome muito significativo em
decorrncia da generalizao do algoritmo que ele encapsula. Por exemplo, no contexto desta
tese o FT funcional Clculo Baseado em Tabela pode ser usado para vrios tipos de regras
de negcio: um valor de vale-refeio que pode ou no ser acrescido ao salrio do funcionrio
dependendo de sua faixa salarial; um desconto na conta de gua para usurios cujo consumo
esteja, por exemplo, entre 11 e 15 m
3
e um bnus para funcionrios cujo nmero de horas
extras mensal superior a 30. Assim, uma estratgia que foi adotada incluir na
documentao do FT algumas palavras-chave e exemplos de sua utilizao.
Depois de constatado que existe um FT que trata do interesse desejado, o segundo
passo consiste em averiguar se as funcionalidades desse FT cobrem os requisitos do caso de
uso. Para isso, os requisitos explcitos do caso de uso, ou do documento de requisitos, devem
ser analisados e contrastados com as caractersticas do FT representadas em seu diagrama de
caractersticas (como aquele mostrado na Figura 4.1). Se as caractersticas do FT forem
suficientes para a implementao do caso de uso um forte indcio que ele pode ser usado. Se
esse no for o caso, deve-se comparar o esforo necessrio para a implementao da(s)
nova(s) caracterstica(s) com as vantagens que isso pode trazer, o que depender de
Captulo 6 ProFT/PU
157
particularidades da organizao, da equipe de desenvolvimento e da quantidade de recursos
disponveis.
Mesmo quando as caractersticas do FT forem suficientes, o processo de anlise deve
ainda continuar. Uma situao que pode ocorrer o FT possuir todas as caractersticas
necessrias para cobrir os requisitos, porm, os requisitos da aplicao exigirem certas
particularidades que exigem modificaes nas caractersticas. Por exemplo, pode ser que o
interesse de autenticao que deve ser implementado exija que o controle de tentativas erradas
seja limitado pelo tempo entre uma tentativa e outra. Pode ser que essa caracterstica do FT
possua apenas a opo para fazer esse tipo de controle diariamente. Dessa forma, deve-se
ponderar o esforo necessrio para realizar adaptaes no FT para que ele possua a nova
funcionalidade. Na Seo 4.3.2. foram mostrados trs tipos de adaptaes que podem ser
feitas no FT de persistncia. Dependendo do nvel de conhecimento da equipe de
desenvolvimento e de sua familiaridade com o FT, esse tipo de adaptao pode ser feito
rapidamente.
Quando no h um FT que possa ser utilizado, h basicamente trs caminhos que
podem ser seguidos. O primeiro implementar o caso de uso normalmente com orientao a
objetos. Entretanto, se o interesse j foi considerado como transversal isso resultar nos
problemas de entrelaamento e espalhamento j comentados anteriormente. O segundo
implementar o caso de uso com POA, mas sem a inteno de transform-lo em um FT. uma
estratgia melhor do que a primeira porque evita os conhecidos problemas, porm, no
colabora para a evoluo do repositrio disponvel. A terceira opo consiste em implementar
o novo caso de uso como um FT e adicion-lo no repositrio disponvel. Essa opo a mais
interessante do ponto de vista de evoluo do repositrio, pois o novo FT deve ser adicionado
a ela.
Os critrios devem ser aplicados para cada caso de uso listado na Tabela de
Candidatos a Aspectos. O processo de aplicao dos critrios envolve a criao de uma tabela,
chamada Tabela de Aspectos, em que os critrios devem ser aplicados para cada caso de uso.
Essa tabela contm um parecer final optando pela implementao com aspecto, pela
implementao convencional ou pelo adiamento da deciso, o que coloca o caso de uso em
situao pendente, que deve ser resolvida futuramente. importante destacar que nem sempre
possvel realizar o adiamento dessa deciso porque o caso de uso pode ser necessrio na
iterao atual. Nesse caso, deve-se tomar uma deciso com base no que h disponvel sobre o
caso de uso, isto , sua descrio e sua natureza. Se a incerteza for grande, talvez seja melhor
optar por uma implementao convencional.
Captulo 6 ProFT/PU

158
Um modelo para essa tabela pode ser visto na Tabela 6.12. A sexta coluna consiste no
parecer final, informando se o caso de uso deve ser implementado com aspectos ou no. Os
casos de uso que devem ser implementados com aspectos so chamados de casos de uso
aspectuais. A stima coluna deve ser marcada com um x depois que o caso de uso for
implementado. Note-se que o preenchimento da tabela consiste em responder sim ou no para
as perguntas da Tabela 6.10. A coluna Framework Transversal deve ser preenchida com S ou
N informando se h ou no um FT que possa ser utilizado para apoiar a implementao do
caso de uso. Em caso de dvida deve-se colocar um ponto de interrogao, que servir como
marcao, indicado que em iteraes posteriores esse caso de uso dever ser analisado com
mais cautela com o objetivo de identificar se algum dos FTs disponveis poder ser usado para
apoiar sua implementao. A coluna Implementa como Aspecto? tambm pode ser
preenchida com a palavra Adiada indicado que ainda h dvida se o caso de uso deve ser
implementado com aspectos ou no. Dessa forma, as prximas iteraes devem novamente
reavaliar esse caso de uso com o objetivo de esclarecer a dvida.
Tabela 6.12 Modelo para Tabela de Aspectos
Casos de Uso Tipo Atomicidade Volatilidade Framework
Transversal
Implementa
como
Aspecto?
Implementado
Caso de Uso 1 nf - - S sim
Caso de Uso 2 f s s S sim
Caso de Uso 3 f n - N no
Caso de Uso 4 f s n N Adiado

Em se tratando de requisitos no-funcionais, no h muita dvida se devem ou no ser
implementados com aspectos, vide a grande quantidade de trabalhos publicados nesse sentido.
Entretanto, o mesmo no ocorre quando os requisitos so funcionais (Suve et al, 2005;
Cibrn et al, 2003). Entre os motivos para implementar requisitos funcionais como aspectos
est o fato de serem extenses, adicionarem comportamentos a outros casos de uso em pontos
especficos e serem independentes. Alm disso, os casos de uso funcionais podem ser
variabilidades, pontos de extenso, implementao de requisitos volteis, ou seja, requisitos
que se sabe previamente que podem mudar durante o ciclo de vida do software, o que tambm
justificaria sua implementao como um aspecto (Moreira e Arajo, 2004).
Por outro lado, dentre os motivos para implementar os casos de uso transversais
funcionais com orientao a objetos est o fato de que esses casos de uso podem ter
caractersticas de negcio especficas para uma aplicao, no possuir possibilidades de
generalizao e reso e a implementao como aspecto ser mais complexa do que
simplesmente criar mdulos internos aos componentes e implementar o comportamento
Captulo 6 ProFT/PU
159
apenas com chamadas a operaes. Alm disso, separar funcionalidades fortemente acopladas
em componentes distintos aumenta a necessidade de comunicao entre os componentes, e,
conseqentemente, a complexidade da composio. necessrio que se avalie as vantagens e
desvantagens em implementar um determinado caso de uso como aspecto ou no, se
realmente mais fcil e se auxilia no melhor entendimento do sistema, na manuteno e na
evoluo.
6.4.2.2 - Selecionar Aspectos para a Iterao Atual
Esta atividade consiste em selecionar os aspectos da Tabela de Aspectos, criada na atividade
anterior, que devem ser implementados na iterao atual. A deciso de implementar ou no
um determinado aspecto na iterao atual depende de vrios fatores, entre eles est a natureza
do aspecto, que pode impossibilitar seu acoplamento em um momento posterior, o tempo
inicial que foi planejado para a iterao atual e tambm a necessidade do aspecto na iterao
atual. Em relao a esse ltimo tpico, o aspecto pode implementar alguma funcionalidade
necessria na iterao atual, ento ele deve ser implementado rapidamente. Geralmente isso
ocorre com aspectos funcionais que precisam ter sua funcionalidade validada.
A deciso por no implementar um aspecto na iterao atual deve ser feita com
cautela, pois h determinados interesses que no so totalmente ortogonais funcionalidade
do sistema e seu acoplamento pode ser dificultado se for protelado para o final (Colyer et al.,
2004). Entretanto, h interesses, e conseqentemente FTs, que podem ser acoplados depois
que a parte base do sistema estiver pronta, por exemplo, Registro de Acesso e Rastreamento
de Operaes.
Tomando cincia desses fatores que podem influenciar a tomada de deciso nesta
atividade, a pessoa responsvel pelo desenvolvimento tem vrias alternativas, por exemplo,
acoplar os aspectos no momento em que so identificados, ou deixar para o final todos os
aspectos cuja natureza seja completamente ortogonal, ou ainda pode ser realizado um misto
das alternativas anteriores, acoplando alguns aspectos durante o desenvolvimento e deixando
alguns para o final.
Os aspectos que sero implementados na iterao atual devem ser listados na Tabela
de Acompanhamento da Implementao de Aspectos, cujo modelo pode ser visto na Tabela
6.13. Essa tabela deve ser continuamente atualizada medida que o desenvolvimento
progride, registrando os aspectos que foram implementados em iteraes anteriores. Depois
que esta tabela foi elaborada e o aspecto foi implementado, deve-se atualizar as tabelas Tabela
de Aspectos e a Tabela de Candidatos a Aspectos para que a coluna implementado de
ambas as tabelas seja marcada com um X.
Captulo 6 ProFT/PU

160
Um ponto que merece destaque aqui quanto ao momento correto de se efetuar o
projeto e o acoplamento dos aspectos com a parte base do sistema. Isso depende do tipo do
aspecto; se o aspecto selecionado para esta iterao for completamente ortogonal
funcionalidade da parte base, ele pode ser projetado e acoplado apenas no final da iterao ou
mesmo no final de todo o processo. J aspectos que disponibilizam operaes e mtodos para
as classes da parte base utilizarem, devem ser acoplados antes que os diagramas de interao
sejam elaborados. Isso ocorre porque durante a elaborao desses diagramas os mtodos e
operaes introduzidos pelos aspectos devem ser considerados. Um exemplo clssico desse
tipo de aspecto a persistncia.
Tabela 6.13 Modelo de Tabela de Acompanhamento da Implementao dos Aspectos
No. Iterao Aspecto
1. da Elaborao Aspecto1
2. da Elaborao Aspecto2
Aspecto3
1. Da Construo Aspecto4
Aspecto5
Aspecto6

6.4.2.3 Projetar Aspectos
Esta atividade tem como objetivo desenvolver modelos de projeto para os aspectos alocados
para a iterao atual. Se esses aspectos possurem FTs que podem ser utilizados para sua
implementao, no h necessidade de desenvolver modelos de projeto para eles, pois os FTs
j possuem esses modelos prontos. Caso contrrio h trs opes possveis. A primeira
projetar o novo aspecto de forma tradicional, sem a preocupao de tornar seu cdigo
genrico. Essa opo faz com que o novo aspecto se torne parte integrante da arquitetura da
aplicao, dificultando seu reso durante o desenvolvimento de novas aplicaes.
A segunda e a terceira opes possuem como objetivo projetar o aspecto de forma
genrica para que possa ser reusado posteriormente. Isso pode resultar em uma nova famlia
de FTs ou em uma nova caracterstica de uma das famlias j existentes. Geralmente o aspecto
adicionado em uma famlia j existente se ele uma caracterstica de algum interesse que j
est implementado como um FT, caso contrrio inicia-se uma nova famlia.
Quando os aspectos devem ser projetados de forma genrica, como o caso para a
segunda e a terceira opes, o projeto deve ser feito utilizando os gabaritos da abordagem
Tema (Clarke e Baniassad, 2005), que permite projetar o interesse transversal sem saber os
pontos de juno do cdigo-base que sero afetados.
A segunda opo consiste em projetar somente a parte de composio do aspecto de
forma abstrata, com conjuntos de juno abstratos, por exemplo. No h preocupao inicial
Captulo 6 ProFT/PU
161
em generalizar o comportamento ou incluir variabilidades e alternativas de composio
(padro Capturador de Dados). Assim, o aspecto projetado rapidamente, facilitando tambm
sua posterior implementao. A incluso de variabilidades e alternativas de composio se d
conforme esse aspecto vai sendo reusado em outros contextos. Essa opo factvel quando
os prazos esto apertados e no h uma equipe especializada no desenvolvimento de FTs.
A terceira opo consiste em j projetar o aspecto como um FT, generalizando no
apenas a parte de composio, mas tambm o comportamento, o que muitas vezes exige o uso
de reflexividade. Tambm j devem ser includas, na medida do possvel, variabilidades e
alternativas de composio (no caso de interesses dependentes de contexto). Para a
identificao de variabilidades deve ser realizada anlise de domnio, o que tambm pode
auxiliar a identificar se o interesse dependente de contexto, o que exigiria a utilizao do
padro Capturador de Dados. Durante a anlise de domnio tambm pode surgir a
possibilidade de implementar alguma variabilidade/caracterstica como um FT.
Assim como na segunda opo, e como qualquer processo de evoluo de
frameworks, a identificao de todas variabilidades de um domnio difcil inicialmente.
Novas variabilidades, caractersticas e alternativas de composio podem surgir quando o FT
for reusado em algum contexto novo.
Um dos fatores que pode colaborar com a adoo da terceira opo a experincia da
equipe de desenvolvimento no domnio do interesse. Nesse caso, no seria gasto muito tempo
com anlise de domnio para a identificao de algumas variabilidades. Outro fator que pode
direcionar a escolha dessa opo a existncia de outras aplicaes em desenvolvimento que
tambm faro uso do FT.
Tanto na segunda quanto na terceira opo, a arquitetura para FTs apresentada no
Captulo 3 pode ser utilizada. Em particular, na segunda alternativa, mesmo que no haja mais
de uma variabilidade e de uma alternativa de composio aconselha-se a utilizao da
arquitetura proposta, pois isso pode facilitar a evoluo do FT quando novas variabilidades e
alternativas tiverem que ser adicionadas.
6.4.2.4 Acoplar Aspectos com a Base
Esta atividade tem como objetivo projetar o acoplamento dos aspectos com a parte base do
sistema, o que pode ser feito com os gabaritos da abordagem Tema (Clarke e Baniassad,
2005). Consiste em desenvolver um modelo de projeto que una o modelo da parte base que
foi desenvolvida at este momento, com o modelo de projeto do aspecto desenvolvido na
atividade anterior. Esse modelo de projeto chamado de modelo de projeto combinado ou
viso de composio.
Captulo 6 ProFT/PU

162
No caso da existncia de um FT, a integrao dos modelos consiste basicamente em
determinar os pontos da aplicao em que os aspectos iro atuar e as classes que devem ser
criadas durante a utilizao do framework. Em outras palavras, o processo de integrao dos
modelos consiste no processo de reso de um FT, o qual possui as etapas de instanciao e de
composio. Essa tarefa de combinar os modelos de projeto auxilia na identificao das
classes que devem ser criadas durante a implementao, quando o FT deve ser efetivamente
instanciado e acoplado com a aplicao.
Neste momento, algumas particularidades do FT podem influenciar a ordem da
composio. Por exemplo, o FT de persistncia possui duas partes bem distintas que podem
ser acopladas em tempos diferentes a um cdigo-base. A primeira a persistncia em si, que
consiste em um conjunto de operaes de armazenameto/consulta/remoo que so
introduzidas nas classes da camada de domnio e que so utilizadas pelas classes da camada
de interface e classes controladoras. Essa parte deve ser acoplada antes que os diagramas de
interao sejam construdos. A segunda a parte que trata da conexo com o banco de dados,
que exige a definio de pontos do cdigo-base onde a conexo deve ser aberta e fechada.
Geralmente as conexo so estabelecidas e encerradas quando eventos de sistema so
disparados, que geralmente ocorrem nas classes de interface e controladoras.
A primeira parte do FT de persistncia deve ser acoplada s classes de domnio antes
do projeto e da implementao das operaes de sistema porque a implementao dessas
operaes geralmente exige que as operaes fornecidas pelo framework estejam disponveis.
Entretanto o acoplamento da segunda parte talvez no possa ser feito nos pontos reais
(pontos de juno do cdigo-base em que o acoplamento ser definitivo, isto , depois que o
sistema for colocado em produo sero os pontos em que o framework ir atuar) do cdigo-
base ao mesmo tempo em que a primeira. Isso ocorre porque a funcionalidade de conexo
com o banco de dados geralmente acoplada em classes de interface que talvez ainda no
tenham sido projetadas. O problema que para testar as operaes de sistema necessrio
que a conexo esteja funcionando, caso contrrio no haver acesso ao banco de dados. Dessa
forma, depois que as classes controladoras e suas operaes de sistema forem projetadas, a
parte de conexo do FT de persistncia deve ser acoplada, mesmo se o acoplamento tiver que
ser feito em pontos fictcios, como por exemplo nas operaes de sistema das classes
controladoras ou em programas criados especificamente para isso. Por outro lado, se as
classes reais em que a conexo deve ser aberta e fechada j estiverem implementadas no h a
necessidade de simulao. Isso evidencia uma particularidade importante da programao
orientada aspectos, que a capacidade de se acoplar e desacoplar facilmente de variados
Captulo 6 ProFT/PU
163
pontos do cdigo-base. Fazer o mesmo com uma implementao orientada a objetos exigiria
modificaes invasivas nesses pontos fictcios. Note-se que mesmo utilizando uma tcnica de
simulao da conexo, a infra-estrutura real de desenvolvimento est presente na arquitetura
do sistema.
Outro ponto importante que os requisitos da aplicao que est sendo desenvolvida
podem exigir determinadas particularidades no FT. Assim, como foi mostrado no Captulo 4,
o acoplamento de caractersticas no FT pode ser feito antes ou depois da composio com a
aplicao.
Na Figura 6.9 mostrado como deve ser feito o projeto da etapa de composio entre
dois modelos. O pacote OperationLog representa um tema transversal que ir afetar a
aplicao nos pontos de juno fornecidos no relacionamento de ligao entre os pacotes.
Assim, os mtodos gerarFatura() da classe SistemaFaturamento, o mtodo doGet()
da classe srvOcuparReserva e o mtodo doPost() da classe
srvConsultarNumeroReservas sero afetados pelo comportamento de registro de
operaes como mostrado no diagrama de seqncia. Quando algum desses mtodos for
executado, o mtodo writeFileBefore() ser invocado para armazenar em algum
dispositivos persistente informaes sobre o contexto de execuo do mtodo. Em seguida, o
comportamento original do mtodo chamado, como representa o mtodo
do_operationToBeLogged(), e em seguida o mtodo writeFileAfter() tambm
executado.
6.4.2.S Desenvolver Diagramas de Interao
O objetivo desta atividade a identificao de operaes, mtodos e classes de software. Para
isso, devem ser elaborados diagramas de interao de seqncia ou colaborao para os
eventos importantes do sistema que esto sendo tratados nesta iterao. Tambm deve-se
cuidar para que diagramas de interao desenvolvidos em iteraes anteriores sejam
atualizados se for necessrio.
Quando o FT de persistncia j foi acoplado neste ponto do processo, um ponto
importante desta atividade considerar, durante a elaborao dos diagramas, que alguns
mtodos de persistncia j existem e no precisam ser identificados, como por exemplo
findlike(), setDBToObject() e save(). Portanto, o engenheiro de software pode se
concentrar na identificao e refinamento de operaes de nvel mais alto de abstrao.
Apesar deste processo possuir atividades especficas para a identificao de aspectos,
nada impede que candidatos a aspectos sejam descobertos no decorrer das atividades
convencionais do processo, como criao de diagramas de interao, diagramas de classes e
Captulo 6 ProFT/PU

164
elaborao de contratos. Isso pode acontecer porque nas atividades que so especficas para a
identificao de aspectos aplicam-se os critrios para os caso de uso, que tem um nvel de
abstrao alto comparado com os artefatos gerados durante o projeto. Assim, funcionalidades
menores que so parte do comportamento de um caso de uso, e que so adequadas para serem
implementadas como aspectos, podem passar despercebidas durante o processo de
identificao em conseqncia do nvel de abstrao com que os critrios so utilizados. Isso
pode ocorrer com requisitos volteis, variabilidades e caractersticas que, muitas vezes, so
funcionalidades menores que fazem parte do comportamento de um caso de uso, e que s so
percebidos quando o nvel de detalhes aumenta.

Figura 6.9 Exemplo de Modelo de Projeto Combinado
Note-se que o aparecimento de candidatos a aspectos durante o decorrer do processo
no significa que as atividades especficas falham. O que ocorre que essas atividades so
mais direcionadas identificao de interesses transversais que atuam diretamente na
aplicao e no de requisitos volteis ou outras funcionalidades menores que atuam como
parte de outras funcionalidades.
OperationLog
< ClassToBeAffected.operationToBeLogged >
OperationLogClass
writeFileBefore()
getObjectName()
writeFileAfter()
createFileName()
createLogFile()
writeLogFile()
verifyObject()
ClassToBeAffected
operationToBeLogged()
do_operationToBeLogged()
o : ClassToBeAffected : Operat ionLogClass
operat ionToBeLogged( )
writeFileBefore( )
do_operationToBeLogged( )
writeFileAfter( )
Applicacao
bind [<SistemaFaturamento.gerarFatura()
srvOcuparReseva.doGet()
SistemaFaturamento.gerarFaturaReservaVencida()
srvReajustarTiposSelecionados.doGet()
srvListarReservasPeriodo().doGet()
srvConsultarNumeroReservas().doPost()>]
Captulo 6 ProFT/PU
165
Embora a atividade Identificar Aspectos utilize um critrio especfico para a
identificao de requisitos volteis, que o critrio volatilidade, ele aplicado para casos
de uso, visando a identificar se o caso de uso voltil. Portanto, as funcionalidades candidatas
a aspectos com maior possibilidade de emergir durante o decorrer do processo so os
requisitos volteis e no interesses transversais.
6.4.2.6 - Desenvolver Modelo de Classes de Projeto
Esta atividade tem como objetivo elaborar o modelo de classes de projeto para os casos de uso
selecionados para esta iterao. Esta atividade possui uma sinergia muito grande com a
atividade de elaborao dos diagramas de interao, pois elas se complementam na construo
dos modelos.
A elaborao do modelo de classes de projeto deve ser feita com cuidado quando a
deciso foi utilizar o FT de persistncia. Isso ocorre porque seu uso impe certas restries
arquitetura do sistema e se essas restries no forem consideradas no modelo de classes de
projeto, o acoplamento do FT de persistncia, seja neste ponto do processo ou no final, pode
exigir mudanas de projeto significativas. Um exemplo de uma restrio arquitetural imposta
pelo framework que, quando h associaes 1 para n, o atributo que representa a associao
deve estar em uma das classes, e no nas duas. Outro exemplo no caso de classes de
associao, em que o nome deve obrigatoriamente ser formado pela juno dos nomes das
duas classes relacionadas.
Com a criao dos diagramas de colaborao e a descoberta de mtodos e outras
restries de projeto, o modelo conceitual comea a ser transformado no modelo de classes de
projeto, em que as classes agora representam tipos de uma linguagem de programao.
6.4.2.7 - Projetar Modelo de Dados
O objetivo nesta atividade desenvolver o modelo de banco de dados para o sistema. Se o FT
de persistncia estiver sendo utilizado, o desenvolvimento do modelo deve ser feito
sinergicamente com a atividade anterior, pois h um mapeamento que deve ser seguido entre
o modelo de classes de projeto e o modelo do banco de dados. Os detalhes desse mapeamento
so encontrados na documentao do FT de persistncia.
6.4.2.8 Atualizar Regras de Composio
Esta atividade tem como objetivo atualizar as regras de composio do modelo de projeto
combinado. Essas atualizaes so necessrias quando o conjunto de casos de uso alocado
para a iterao atual deu origem a novos elementos (classes/mtodos/atributos) que tambm
precisam ser afetados pelos aspectos que j esto presentes no sistema. Por exemplo, suponha
Captulo 6 ProFT/PU

166
que o FT de persistncia j esteja acoplado ao sistema e que suas regras de composio
explicitam cinco classes de domnio afetadas. Se novas classes de domnio so includas no
sistema e precisam de operaes de persistncia, as regras de composio do FT precisam ser
atualizadas para tambm considerar essas novas classes.
6.4.2.9 - Desenvolver Modelo de Projeto Composto
Esta atividade tem como objetivo gerar o modelo de projeto composto para os casos de uso
considerados nesta iterao. Mesmo quando no houve a identificao de novos aspectos na
iterao atual, o modelo de projeto composto talvez tenha que ser gerado novamente. Isso
ocorre sempre que as novas entidades (classes/mtodos/atributos) adicionadas na parte base
do sistema precisam ser afetadas pelos aspectos que j esto acoplados. Em outras palavras, se
a atividade Atualizar Regras de Composio foi realizada, porque foram acrescentadas
certas entidades na parte base do sistema que precisaram ser afetadas pelos aspectos que j
estavam acoplados.
O modelo de projeto combinado representa a unio entre o modelo de projeto do
aspecto e o modelo de projeto de uma determinada parte do sistema que est sendo
desenvolvido. O modelo de projeto do aspecto, que no caso um FT, no ser modificado
com o decorrer das iteraes, mas o mesmo no ocorre com o modelo de projeto da parte
base. Isso exige que as regras de acoplamento sejam constantemente atualizadas. Assim, esta
atividade tambm tem como objetivo atualizar as regras de acoplamento no decorrer das
iteraes.
6.4.2.J0 - Desenvolver Viso da Arquitetura
O objetivo desta atividade elaborar um modelo em alto nvel de abstrao que mostra a
arquitetura do sistema. O objetivo conseguir identificar facilmente os aspectos e FTs que
esto acoplados poro do sistema projetada at este momento. Esse modelo deve ser
constantemente atualizado medida que novos aspectos/FTs so adicionados ao sistema
durante o decorrer das iteraes.
O modelo denominado Viso da Arquitetura e a notao sugerida a proposta por
Krechetov et al. (2006). O nvel de detalhes exibidos no diagrama fica a cargo do
desenvolvedor. Na Figura 6.10 mostrada a Viso da Arquitetura para um sistema hipottico
em um alto nvel de abstrao. H trs FTs acoplados aplicao e um aspecto normal
chamado Empresa, que est sendo representado pela nota. Assim, pode-se facilmente obter
uma viso ampla da arquitetura do sistema visualizando os mdulos (componentes-base e
aspectuais) que o compem. Note-se que, neste nvel de abstrao, no possvel identificar
se o relacionamento que os componentes aspectuais mantm com os outros componentes
Captulo 6 ProFT/PU
167
esttico ou dinmico. Entretanto, a notao permite que detalhes adicionais sejam fornecidos
(Krechetov, et al., 2006). Como essa abordagem de modelagem baseada na UML, uma
vantagem que apoio automatizado facilmente obtido.
A prxima atividade complementa este modelo, pois mantm um registro dos pontos
de juno da aplicao que so afetados por cada um dos FTs mostrados neste modelo. Uma
alternativa seria manter esse registro de pontos de juno no modelo, entretanto como isso
poderia comprometer a sua legibilidade optou-se por manter o registro em uma tabela, que
mostrado na atividade seguinte.
6.4.2.JJ Registrar Pontos de Juno
Quando aspectos so utilizados durante o desenvolvimento de um sistema, pode ocorrer que o
mesmo ponto de juno seja afetado por mais de um aspecto, o que pode gerar inconsistncias
e conflitos se um dos aspectos altera dados que o outro utiliza. Nesse sentido, o objetivo nesta
atividade averiguar a necessidade de criao de algum esquema de precedncia de atuao
entre os aspectos.

Figura 6.10 Viso da Arquitetura
Para isso, aconselha-se manter um registro dos pontos de juno afetados e dos
aspectos que afetam esses pontos de juno. Esse registro auxilia a identificar pontos de
juno que so afetados por aspectos diferentes e, nesse caso, deve-se averiguar se
necessrio elaborar um esquema de precedncia de atuao entre eles, o que pode ser feito
com as declaraes declare precedence da linguagem AspectJ, por exemplo.
Dessa forma, uma atividade que deve ser conduzida o Registro de Pontos de Juno.
Esse registro consiste em uma tabela em que so relatados os pontos de juno do sistema
afetados por FTs e outros aspectos. Como aspectos e FTs tambm possuem pontos de juno,
eles devem ser considerados durante a elaborao da tabela.
Empresa
Apli cacao
<<component>>
<<crosscuts>>
FT Persistencia
<<aspectual component>> <<crosscuts>>
FT Autenticacao
<<crosscuts>>
FT Cont role de Acesso
<<crosscuts>>
Aspecto
Simples
<<crosscuts>>
Captulo 6 ProFT/PU

168
A Tabela 6.14 o modelo que deve ser utilizado para a elaborao do Registro dos Pontos de
Juno. Na primeira coluna devem ser colocados os FTs ou aspectos, e na segunda, terceira e
quarta colunas devem ser discriminados os pontos de juno afetados por cada um. Podem ser
utilizados caracteres coringa para representao dos pontos de juno, como por exemplo,
asterisco (*) e dois pontos horizontais (..). Dessa forma, aspectos homogneos que afetam um
nmero grande de pontos de juno podem ser representados de forma mais legvel, como o
FT1. Esse FT afeta o mtodo someMethod() de qualquer classe presente no sistema, como
est representado pelo asterisco na coluna Classe. A Tabela tambm deve ser utilizada para
registrar pontos de juno de aspectos ou FTs afetados por outros aspectos ou FTs. Por
exemplo, o Aspecto2 afeta o advice1 e o mtodo methodD() do aspecto Aspecto3.
Tabela 6.14 Modelo para o Registro de Pontos de Juno
Pontos de Juno Afetados
Unidades de Software
FT/Aspecto
Mtodo/atributo/construtor/adendo
Classe Aspecto
FT1 someMethod() *
methodA() Class1
methodB() Class1
FT2
methodC() Class1
FT3 new() Class2
init*() Class3
methodA() Class1
Aspecto1
methodB() Class1
Aspecto2 Advice1 Aspecto3

methodD() Aspecto3
Aspecto3
methodE() Class4

A elaborao desta tabela facilita a identificao de pontos de juno que so
compartilhados por dois ou mais aspectos, por exemplo: o FT2 afeta os mtodos methodA()
e methodB() da classe Class1, que tambm so afetados pelo Aspecto1. Quando esse tipo
de situao encontrado, aconselha-se destacar os FTs e os pontos de juno compartilhados.
Dessa forma, o FT2 e o Aspecto1 devero ser analisados para de averiguar se h necessidade
de criar um esquema de precedncia entre eles.
Embora a elaborao desta tabela seja feita na disciplina de projeto, natural que ela
seja atualizada durante a implementao, pois s durante essa disciplina que os pontos de
juno projetados aqui so realmente utilizados, podendo haver modificaes significativas.
Sempre que as regras de composio dos FTs que j esto acoplados ao sistema so
atualizadas, o Registro de Pontos de Juno tambm deve ser atualizado e uma anlise deve
novamente ser feita com o objetivo de verificar a existncia de pontos de juno afetados por
dois ou mais FTs e/ou aspectos.
O FT de persistncia e o de controle de acesso so excees aos problemas que
podem ocorrer com o compartilhamento de pontos de juno. O FT de persistncia j possui
Captulo 6 ProFT/PU
169
implementado internamente um mecanismo de precedncia sobre qualquer outro aspecto do
sistema. Isso necessrio para que a conexo seja estabelecida antes que qualquer operao
possa ser executada. Da mesma forma, o FT de controle de acesso tambm j possui
implementado internamente um mecanismo que fornece prioridade de atuao ao FT de
autenticao. No h como verificar se um usurio pode executar determinadas operaes se
ele no estiver autenticado no sistema.
Alm do problema de que dois ou mais aspectos podem afetar o mesmo ponto de
juno, outra situao que pode ocorrer a interao inesperada entre aspectos (aspect
interactions). Ocorre quando o comportamento de um aspecto afetado pelo comportamento
de outro aspecto. O tratamento para este problema est fora do escopo desta tese, mas pode
ser tratado pela abordagem desenvolvida por Douence et al. (2002) (Douence et al., 2002
apud (Blair et al., 2005)
23
.
6.4.3 Disciplina Implementao
Nesta disciplina o objetivo traduzir os modelos de projeto em cdigo-fonte. comum que
certos detalhes de projeto sejam identificados durante a realizao desta disciplina, exigindo
atualizaes nos modelos j obtidos.
As atividades desta disciplina podem ser vistas na Figura 6.11 no formato SADT
(Ross, 1977). As atividades que no so particulares do ProFT/PU so Implementar Classes
de Domnio, Implementar Banco de Dados, Implementar Classes Controladoras e Testar
Sistema, j que so encontradas em qualquer processo de desenvolvimento. Entretanto, elas
tambm possuem algumas diferenas por conta da presena de aspectos durante o
desenvolvimento. A atividade Atualizar Regras de Composio s deve ser realizada se a
poro do sistema recm-implementada na iterao atual tambm precisa ser afetada pelos
aspectos j presentes no sistema. A atividade Implementar Aspectos s deve ser realizada se a
Tabela de Acompanhamento da Implementao de Aspectos contm aspectos que devem ser
implementados na iterao corrente. A posio dessas atividades pode variar ligeiramente
dentro desta disciplina, por exemplo, a atividade Implementar Aspectos pode tambm ser
realizada depois que as interfaces e classes controladoras foram desenvolvidas. Nas prximas
sees cada uma das atividades descrita com mais detalhes.
6.4.3.J - Implementar Classes de Dominio

23
Douence, R., Fradet, P., Sdholt, M. A framework for the detection and resolution of aspect interactions. In:
1
st
ACM Conference on Generative Programming and Component Engineering (GPCE), LNCS, vol 2487.
Springer-Verlag, Berlim, 173-188, 2002.
Captulo 6 ProFT/PU

170
O objetivo nesta atividade implementar as classes de domnio, seus atributos, mtodos de
acesso (sets e gets) e relacionamentos com outras classes para os casos de uso
selecionados para esta iterao. As classes que pertencem a aspectos funcionais tambm
devem ser implementadas nesta atividade, j que fazem parte da funcionalidade do sistema.
Contudo, como no conveniente que a parte base dependa da parte transversal, se houver
algum relacionamento nessa direo, sua implementao deve ser feita de forma a no criar
dependncia da classe base com a classe que pertence ao interesse transversal. Assim, sugere-
se que, nesta situao, a classe que pertence ao interesse transversal seja desenvolvida
normalmente, porm o atributo que representa o relacionamento deve ser introduzido na
classe base por meio de declaraes intertipo da linguagem AspectJ, por exemplo.

Figura 6.11 Atividades da Disciplina de Implementao
6.4.3.2 - Implementar o Banco de Dados
Esta atividade tem como objetivo implementar o banco de dados. Isso deve ser feito de forma
convencional traduzindo o modelo de dados em tabelas de banco de dados. Caso o FT de
persistncia esteja sendo utilizado, deve-se cuidar para que as convenes exigidas sejam
seguidas como descrito na documentao desse FT.
Disciplina Implementao
Implementar
Classes de
Domnio
Modelos de
Projeto
Interessados
no sistema
Implementar
Classes
Controladoras
Testar Sistema
Atualizar Regras
de Composio
Classes
Implementadas
Implementar
Banco de Dados
Implementar
Aspectos
Implementar
Interfaces
Banco de
Dados
Projeto com Regras
de Composio
Atualizadas
Aspectos
Implementados
Interfaces
Implementadas
Classes Controladoras
Implementadas
Poro do Sistema
Implementada e Testada
Diagrama de
Classes de Projeto
Diagrama de
Classes
Modelo de Projeto
Combinado
Lxperincia
Lxperincia
Lxperincia
Lxperincia Diagramas de
Interaao
Diagramas de
Interaao
Diagrama de
Classes de Projeto
N
N
Captulo 6 ProFT/PU
171
Nesta atividade o objetivo atualizar as regras de composio dos aspectos que j esto
acoplados poro desenvolvida do sistema. Essas atualizaes so necessrias quando os
novos elementos (classes/mtodos/atributos) introduzidos no sistema na iterao atual
precisam ser afetados pelos aspectos que j estavam acoplados ao sistema. Uma maneira de
descobrir se as regras de composio devem ser atualizadas verificar se houve atualizaes
na atividade Atualizar Regras de Composio da disciplina Projeto. Em caso positivo, as
atualizaes tambm devem refletidas nesta atividade.
A posio desta atividade nesta disciplina pode variar, dependendo do aspecto ou do
FT que estiver acoplado ao sistema. No caso do FT de persistncia, este o momento correto
de fazer atualizaes referentes parte de persistncia propriamente dita, isto , a parte do FT
responsvel pela introduo das operaes de persistncia. Isso ocorre porque durante a
atividade Desenvolver Classes Controladoras a maior parte das operaes de sistema e
mtodos de granularidade mais fina desenvolvida, que geralmente precisa das operaes de
persistncia. Em relao parte de conexo com o banco de dados, o momento adequado para
se fazer atualizaes aps o desenvolvimento das classes controladoras e interfaces do
sistema. Isso ocorre porque as atualizaes iro necessitar do nome das classes e dos mtodos
dessas classes.
6.4.3.4 Implementar Aspectos
Esta atividade tem como objetivo implementar os aspectos selecionados para esta iterao. A
posio desta atividade na disciplina de implementao pode variar dependendo do FT que
est sendo implementado. Por exemplo, se a implementao de vrias operaes de negcio
necessitam das operaes de baixo nvel introduzidas pelo FT de persistncia, seu
acoplamento deve ser feito antes que essas operaes de negcio sejam implementadas. por
isso que esta atividade encontra-se antes da atividade Desenvolver Classes Controladoras,
pois nessa atividade que a maior parte das operaes e mtodos de negcio implementada.
Para aspectos completamente ortogonais funcionalidade do sistema (Colyer et al., 2004),
como, por exemplo, registro de operaes, a posio desta atividade no processo no
importante porque a parte base no possui dependncia com esse tipo de aspecto.
Pode ocorrer que esta atividade tenha que ser repetida em vrios pontos ao longo da
disciplina de implementao, uma para cada FT, ou at mesmo uma para cada parte de um
FT. Isso acontece porque, em alguns casos, as regras de composio para determinados FTs
s podem ser implementadas depois que alguma parte do sistema seja desenvolvida. Por
exemplo, se o FT de persistncia estiver sendo utilizado, pode ser necessrio seu acoplamento
logo na primeira iterao para que as operaes de persistncia, disponibilizadas por esse FT,
Captulo 6 ProFT/PU

172
estejam disponveis para a implementao de algumas classes da aplicao. Entretanto, pode
ser que a conexo com o banco de dados, que tambm faz parte do FT de persistncia, s
possa ser acoplada ao sistema depois que as classes de interface forem implementadas,
exibindo que essa atividade seja novamente repetida nas prximas iteraes ou mesmo
posteriormente, dentro da mesma iterao.
No caso do cenrio descrito no pargrafo anterior, uma alternativa que pode ser
tomada realizar o acoplamento da conexo em pontos de juno fictcios apenas para a
realizao de testes, e posteriormente, assim que as classes reais estivessem implementadas as
regras de composio seriam atualizadas.
6.4.3.S Implementar Classes Controladoras
Este passo tem como objetivo implementar as classes controladoras e suas operaes. O
modelo de classes de projeto a base para a implementao das classes controladoras e os
diagramas de colaborao e os casos de uso so a base para a implementao das operaes e
mtodos de granularidade mais fina.
Uma deciso importante que pode ocorrer neste ponto do processo decidir se o
framework pode ser usado como est, ou se necessita de adaptaes. No caso do FT de
Persistncia, trs tipos possveis de adaptao foram mostrados na Seo 4.3.
6.4.3.6 Implementar Interfaces
Esta atividade tem como objetivo implementar as classes de interface para o sistema que est
sendo desenvolvido. No caso do sistema de reservas, deve-se desenvolver uma interface para
a realizao de uma reserva e interfaces para os casos de uso gerenciadores de dados. Como o
sistema de reservas est sendo desenvolvido com plataforma Web, optou-se por implementar
as interfaces com servlets, como pde ser visto nos diagramas de colaborao elaborados na
disciplina de projeto.
6.4.3.7 1estar Sistema
Esta atividade deve ser conduzida com o objetivo de testar a poro do sistema desenvolvida
na iterao atual. Como o sistema provavelmente utiliza POA necessrio utilizar alguma
estratgia de teste especfica para esse paradigma. Sugere-se a utilizao de algumas tcnicas
de teste j apresentadas na literatura (Lemos et al, 2003a; Lemos et al., 2003b; Zhao, 2003;
Zhao, 2002; Zhou et al., 2004). Entretanto, como os FTs j se encontram testados, o enfoque
deve ser na poro do sistema que foi desenvolvida.
A realizao de testes funcionais deve ser feita com o objetivo de averiguar se a
funcionalidade esperada para a iterao corresponde com o esperado. Testes de integrao
Captulo 6 ProFT/PU
173
tambm devem ser conduzidos sempre que um novo aspecto ou FT for acoplado ao sistema.
A Viso de Arquitetura um artefato que pode ser utilizado para averiguar a necessidade de
testes de integrao, j que ele mostra os FTs e aspectos acoplados ao sistema. Quando o FT
de persistncia utilizado, o FT de Garantia de Polticas pode ser empregado para averiguar
se o processo de reso foi feito corretamente.
Sempre que regras de composio forem atualizadas tem-se um indcio de que testes
devem ser novamente conduzidos. Isso ocorre porque as atualizaes mostram que
determinados FTs/Aspectos comearam a afetar novos elementos. A Viso de Arquitetura e o
Registro de Pontos de Juno podem ser utilizados para analisar qual FT/aspecto deve ser
novamente testado.
6.4.4 Planejar Iteraes
Esta atividade tem como objetivo avaliar o andamento do processo e realizar ajustes nas
iteraes seguintes, caso ele tenha se desviado do plano inicial. Esses ajustes geralmente
consistem em realocaes de casos de uso para outras iteraes, ou mesmo a deciso por
implementar parte de um caso de uso, ao invs dele todo.
6.S IASL DL CONS1RUO
Esta fase tem como objetivo finalizar o desenvolvimento do sistema concentrando-se nos
casos de uso restantes, os quais possuem um impacto menor na arquitetura do sistema e no
so to importantes do ponto de vista da funcionalidade principal. A estrutura de disciplinas e
atividades dentro desta fase a mesma da fase de elaborao, contudo, a nfase bem maior
no projeto e implementao.
Dependendo da estratgia de desenvolvimento que foi adotada, no final das iteraes
planejadas para a fase de construo pode ser necessrio que vrios aspectos ainda tenham
que ser projetados e implementados. Para identificar os aspectos que ainda no foram
implementados deve-se analisar a coluna Implementado? da Tabela de Aspectos. Se esse
for o caso, deve-se realizar novamente um replanejamento com o objetivo de classificar esses
aspectos e planejar como sero desenvolvidos.
Em relao classificao, sugere-se que os aspectos funcionais sejam implementados
primeiro e depois os no-funcionais. A razo disso que geralmente os casos de uso no-
funcionais afetam a parte base do sistema, e interessante que ela esteja pronta antes que eles
sejam implementados. A existncia de FTs para apoiar a implementao dos casos de uso no
deve ser um critrio de classificao. A prioridade de implementao deve ser ditada por
dependncias intrnsecas existentes entre os interesses, por exemplo, a implementao do
Captulo 6 ProFT/PU

174
interesse de controle de acesso s pode ser feita depois que o interesse de autenticao j
esteja implementado, caso contrrio no ser possvel identificar qual usurio possui acesso a
uma determinada parte do sistema.
Em relao ao planejamento, uma estratgia que pode ser adotada tratar apenas um
FT em cada iterao, assim como foi feito por Soares (2004), a no ser que haja aspectos
intrinsecamente relacionados ou que haja prioridade de implementao entre eles. Tratar cada
aspecto em uma iterao distinta facilita o descobrimento de problemas com o acoplamento,
visto que eles podem ser acoplados e testados individualmente. Pela terminologia definida
neste processo, as iteraes que tratam apenas de aspectos so denominadas iteraes
aspectuais. As disciplinas que possuem mais nfase dentro das iteraes aspectuais so
projeto, implementao e testes. As atividades que ocorrem nas disciplinas mencionadas so
apenas aquelas relacionadas com o projeto e a implementao dos aspectos, por exemplo:
Projetar Aspectos, Desenvolver Viso da Arquitetura, Registrar Pontos de Juno e
Implementar Aspectos.
6.6 CONSIDLRALS IINAIS
O processo de desenvolvimento orientado a aspectos apresentado neste captulo foi elaborado
com base: a) na experincia de desenvolvimento e reso dos FTs apresentados no Captulo 4;
b) no estudo de trabalhos relacionados com desenvolvimento de software orientado aaspectos
e c) no desenvolvimento do sistema de reservas apresentado no Captulo 7. Durante a criao
do processo procurou-se mant-lo independente de tecnologia. Entretanto, se o FT de
Segurana for utilizado a arquitetura que deve ser empregada a mostrada na Figura 4.23.
A maior parte das tabelas utilizadas durante o processo so utilizadas apenas durante o
desenvolvimento e podem ser eliminadas depois que o sistema estiver em produo. Quando
as informaes descritas nas tabelas no puderem ser descartadas, uma alternativa criar
mecanismos para manter as informaes nos modelos de classes, de interao e de pacotes,
porm isso est fora do escopo desta tese.
Uma contribuio do processo apresentado aqui frente aos tradicionais a unio e o
aprimoramento de conceitos, critrios e tcnicas de modelagem de outros trabalhos (Clarke e
Baniassad, 2005; Jacobson e Ng, 2004; Arajo e Moreira, 2002) em um nico processo.
ProFT/PU possui grande enfoque na identificao dos interesses transversais, mas fornece
flexibilidade para que os desenvolvedores possam decidir pela tcnica de implementao que
pode ser usada. Outro diferencial a existncia dos FTs que, em muitos casos, influenciam as
decises tomadas. Por exemplo, a deciso de implementar ou no determinado interesse
Captulo 6 ProFT/PU
175
transversal em uma iterao grandemente influenciado pela existncia de um FT que apia a
implementao do interesse.
Embora diretrizes de anlise, projeto e implementao tenham sido fornecidas, nada
impede a adoo de abordagens mais especficas em cada fase do ciclo de vida. Por exemplo,
na fase de anlise a abordagem de Jacobson e Ng (2004) poderia ser usada para modelar os
casos de uso transversais, desde que fosse adaptado ao modelo iterativo e incremental e que as
atividades das fases seguintes a considerassem. Da mesma forma, a engenharia de requisitos
pode ser mais profundamente tratada se um modelo, como, por exemplo, AORE (Rashid et
al., 2002), fosse utilizado. O objetivo do ProFT foi cobrir todo o ciclo de vida mostrando
como o processo todo pode ser conduzido, acompanhando os interesses transversais desde a
anlise at a implementao em um processo iterativo e incremental.
Um ponto interessante seria fornecer, juntamente com a documentao dos FTs, no
apenas seu projeto, mas tambm seus modelos de anlise. Assim, durante o processo de
desenvolvimento, alm dos modelos de projeto, seus casos de uso e modelos conceituais
tambm poderiam ser reusados.
Embora o processo descrito neste captulo fornea diretrizes para a utilizao da
famlia de FTs, pode ser usado com qualquer repositrio de aspectos reusveis. A
identificao de interesses transversais e os pontos de deciso so independentes da
tecnologia que est disponvel para ser reusada.

Captulo 6 ProFT/PU

176

Captulo 7
e vt o ae |.o ao Pr o1,P|
Neste captulo mostrado o desenvolvimento de um sistema de reserva de uma rede de hotis
utilizando o ProFT/PU. A nfase dada nas fases, disciplinas e atividades que foram
modificadas do PU, ou que foram acrescentadas. As fases e atividades que no diferem do PU
so conduzidas de forma convencional e no so mostradas no decorrer do texto.
No decorrer do captulo, nfase maior dada em atividades ligadas identificao de
interesses transversais e em como a aplicao evolui a cada iterao. Assim, mostram-se todas
as iteraes realizadas para o desenvolvimento do sistema. Como as ltimas iteraes cuidam
de alguns FTs j exemplificados em captulos anteriores, so descritas com menos detalhes.
O sistema utilizado como exemplo um sistema de reservas de acomodaes de uma
rede de hotis retirado e adaptado do livro de Chessman e Daniels (2000), cujo documento de
requisitos pode ser encontrado no anexo 1 desta tese. Nesse sistema, as reservas podem ser
feitas por telefone ou pela Internet. Cada hotel tem diferentes tipos de acomodao que podem
ser reservados por um cliente, cujos dados devem ser registrados no sistema. O cliente pode
confirmar, modificar, cancelar ou ocupar sua reserva (iniciar estada) e receber uma
acomodao do tipo escolhido, nesta ltima situao. No hotel, deve ser possvel fazer as
reservas nos balces de atendimento e nos escritrios. Cada hotel tem um gerente responsvel
por controlar as reservas, mas qualquer usurio autorizado pode faz-las. O tempo desejado
para fazer uma reserva por telefone ou pessoalmente de trs minutos. Para agilizar o
processo, detalhes de clientes que j estiveram no hotel sero armazenados e disponibilizados
para uso. O controle do pagamento das locaes de quarto e taxas por reserva no ocupada
sem cancelamento ser realizado por um sistema de pagamento existente. O hotel possui um
gerente que responsvel pelo gerenciamento do hotel, acomodaes, funcionrios, etc, e um
Captulo 7 Exemplo de Uso do ProFT/PU

178
administrador do sistema que responsvel por gerenciar o sistema, atribuir permisses de
acesso, etc.
Na Seo 7.2, a fase de concepo para o sistema de reservas mostrada. Nas Sees
7.3 e 7.4, as duas iteraes planejadas para a fase de elaborao so apresentadas e nas Sees
7.5 e 7.6 as duas iteraes planejadas para a fase de construo so delineadas. Nas ltimas
trs sees as iteraes aspectuais, que so iteraes que cuidam especificamente de casos de
uso selecionados para serem implementados como aspectos, so descritas.
7.2 IASL DL CONCLPO
7.2.J Disciplina Requisitos
7.2.J.J Identificar Atores e Detalhar Casos de Uso Iuncionais
Na Figura 7.1 mostrado o diagrama de casos de uso para o sistema e hotel e tambm alguns
dos atores identificados.

Figura 7.1 Atores e Diagrama de Casos de Uso Inicial do Sistema de Reservas
7.2.J.2 Identificar e Lspecificar Casos de Uso No-Iuncionais
Neste ponto do desenvolvimento deve ser iniciada a elaborao da Tabela de Interesses
Transversais No-Funcionais. Na Tabela 7.1 so mostrados os interesses no-funcionais
identificados para o sistema de reservas.
Tabela 7.1 Tabela de Interesses Transversais No-Funcionais para o Sistema de Reservas
Interesses No-Funcionais Identificados
Interesse No-Funcional Requisitos Cobertos
Autenticao 13
Controle de Acesso 16.1, 16.2
Registro de operaes 15
Persistncia 17
Cl i ente
Reaj ustar Val or de di ri as Fazer Reserva
Cancel ar Reserva
Al terar Reserva
Consul tar Reservas Di a/Peri odo Consul tar Numero de Reservas
Operador de Reservas
Si stemaFaturamento
gerarFatura()
Ocupar Reserva
No Comparecer
<<extend>>
<<extend>>
179
Depois que os casos de uso no-funcionais foram identificados, devem ser especificados e
integrados no diagrama de casos de uso obtido at o momento. Sugere-se a elaborao de
vises individuais, como mostrado na Figura 7.2.

Figura 7.2 - Caso de Uso No-Funcional Autenticar Usurio Viso Individual de Caso de Uso
7.2.J.3 Planejar Iteraes
Na Tabela 7.2 mostrada a classificao inicial obtida para o sistema de reservas. Os casos de
uso que trabalham mais diretamente com a funcionalidade da reserva esto em posies mais
altas da classificao, os casos de uso gerenciadores de dados ocupam o meio da classificao
e os relatrios, consultas e funcionalidades de apoio esto no final da lista.
Tabela 7.2 Classificao de Casos de Uso para o Sistema de Reservas

Classificao Caso de Uso
1 Fazer Reserva
2 Ocupar Reserva
3 Alterar Reserva
4 Cancelar Reserva
5 No Comparecer
6 Gerenciar Usurios
7 Gerenciar Acomodao
8 Gerenciar Empresas
9 Gerenciar Hotel
10 Gerenciar Tipo de Acomodao
11 Gerenciar Cliente
12 Consulta se acomodao est disponvel
13 Gerar Dados para Faturamento
14 Consulta Nmero de Reservas
15 Reajustar Valor de Dirias
16 Listar Reservas por Perodo
Admi ni strador
Fazer Reserva
Cancel ar Reserva
Al terar Reserva
Ocupar Reserva
No Comparecer
Gerenci ar Usuri os
<<NF>>
Consult ar Numero de Reservas
Consult ar ReservasDi a/Peri odo
Control ar Acesso
<<NF>>
Persi sti r Dados
<<NF>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<constrai n>>
<<constrai n>>
<<constrai n>>
<<constrai n>>

180
O caso de uso Fazer Reserva mostrado na Figura 7.3, por exemplo, possui cinco
conceitos necessrios para sua implementao cliente, acomodao, tipo de acomodao,
reserva e hotel. Se esses conceitos no estiverem disponveis no ser possvel efetuar uma
reserva. Portanto, os casos de uso que envolvem operaes bsicas de persistncia sobre esses
conceitos conhecidos como casos de uso gerenciadores de dados devem ser deslocados
para posies superiores da classificao. Portanto, os casos de uso gerenciadores de dados
que cuidam da persistncia desses conceitos foram deslocados para as posies iniciais da
classificao, como mostrado na Tabela 7.3.

Figura 7.3 Caso de Uso Fazer Reserva
Como o caso de uso Ocupar Reserva utiliza todos os conceitos persistentes exigidos
pelo caso de uso Fazer Reserva e mais o conceito Empresas, ele tambm s pode ser
implementado se o caso de uso Gerenciar Empresas estiver implementado, fazendo com que
esse caso de uso gerenciador de dados tambm seja deslocado para posies iniciais da lista.
Alm disso, o caso de uso Ocupar Reserva tambm depende da existncia do caso de uso
Gerar Dados para Faturamento, o que tambm conduz esse caso de uso para posies mais
prioritrias.
Depois que essa classificao inicial foi obtida, deve-se planejar quantas iteraes
devem ser realizadas e quais casos de uso devem ser trabalhados em cada iterao. Na Tabela
7.3 tambm so mostradas as iteraes estipuladas para o sistema de reserva e os casos de uso
que foram alocados para cada uma. Optou-se por desenvolver quatro casos de uso
gerenciadores de dados e mais o caso de uso Fazer Reserva na primeira iterao. Dessa forma,
uma verso operacional do sistema poder ser obtida no final da primeira iterao, que no
permite alterao, cancelamento, ocupao e cobrana.
Na segunda iterao, as funcionalidades de cobrana, de ocupao da reserva e de
alterao de uma reserva devem ser implementadas. Na primeira iterao da construo, a
Caso de Uso: Fazer Reserva


11. O Operador de Reservas solicita fazer uma reserva.
12. O Operador de Reservas escolhe, em ordem, o hotel, datas de incio e fim da reserva, e tipo de acomodao.
13. O sistema verifica se h acomodao disponvel no perodo especificado no hotel especificado.
14. O Sistema fornece disponibilidade e o preo ao Operador da Reserva.
15. O Operador de Reservas solicita ao sistema a operao de fazer reserva.
16. O Operador de Reservas fornece ao sistema o nome e dados para contato do cliente.
17. O Operador de Reservas fornece ao sistema o e-mail de contato.
18. O Sistema registra a reserva e aloca um cdigo para a reserva efetuada.
19. O Sistema mostra o cdigo da reserva para o Operador da Reserva.
20. O Sistema cria e envia os dados de confirmao da reserva por e-mail para o cliente.
181
funcionalidade de reservas complementada, permitindo que o sistema possa cancelar uma
reserva, e efetuar as operaes cabveis quando o cliente no comparece para ocupar a
reserva. Na segunda iterao da construo consultas e relatrios e o gerenciamento de
usurios so tratados. Entretanto, o planejamento da segunda iterao em diante pode sofrer
alteraes em conseqncia de imprevistos que podem surgir na primeira iterao.
Tabela 7.3 Tabela de Planejamento das Iteraes do Sistema de Reservas

Um artefato que deve ser desenvolvido quando se trabalha com desenvolvimento
incremental e evolutivo a viso de iterao. A primeira iterao do sistema de reservas
ter acesso aos casos de uso mostrados no diagrama mostrado na Figura 7.4. Apesar dos casos
de uso no-funcionais no aparecerem na classificao mostrada na Tabela 7.3, eles so
considerados na iterao, porm isso no significa que devem, obrigatoriamente, ser
implementados na iterao atual.
7.3 IASL DL LLABORAO J. I1LRAO
Depois de finalizado o processo de anlise, identificou-se a ausncia de trechos com
funcionalidades comuns entre os casos de uso desta iterao. Entretanto, uma nova
funcionalidade foi considerada como um caso de uso, que o Enviar Dados por E-mail.

Iteraes Classificao Caso de Uso
1 Gerenciar Acomodao
2 Gerenciar Hotel
3 Gerenciar Tipo de Acomodao
4 Gerenciar Cliente
1 Iterao
5 Fazer Reserva
6 Gerenciar Empresas
7 Gerar Dados para Faturamento
8 Ocupar Reserva
E
l
a
b
o
r
a
o

2 Iterao
9 Alterar Reserva
10 Cancelar Reserva 1 Iterao
11 No Comparecer
12 Gerenciar Usurios
13 Consulta se acomodao est
disponvel
14 Consulta Nmero de Reservas
15 Reajustar Valor de Dirias
C
o
n
s
t
r
u
o

2 Iterao
16 Listar Reservas por Perodo

182

Figura 7.4 Viso de Iterao Fase de Concepo
7.3.J.2 Identificar e Registrar Casos de Uso Candidatos a Aspectos
A anlise deve se restringir aos casos de uso que podem ser acessados na iterao, os quais
podem ser vistos na viso de iterao mostrada na Figura 7.5. Para o sistema de reservas em
questo, trs casos de uso foram considerados como candidatos a aspectos: Persistir Dados,
Registrar Operaes e Enviar Dados por E-Mail. Na Tabela 7.4 so mostrados esses casos de
uso e o critrio que foi utilizado para selecion-lo.

Figura 7.5 Caso de Uso Enviar Dados por E-mail

Tabela 7.4 Tabela de Candidatos a Aspectos do Sistema de Reservas (TPCaUT)
7.3.J.3 Desenvolver Modelo Conceitual
Analisando os casos de uso alocados para a iterao atual, o modelo conceitual mostrado na
Figura 7.6 foi obtido.

Persistir Dados No-funcional Nmero de relacionamentos e Tipo
Registrar Operaes No-funcional Tipo
Enviar Dados por E-
mail
Funcional Um relacionamento de extenso
Regist rar Operaes
<<NF>>
Gerenciar Cliente
Gerenciar Hotel
Gerenciar Tipo Acomodao
Gerenci ar Acomodao
Fazer Reserva
<<extend>>
Persistir Dados
<<NF>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
Regist rar Operaes
<<NF>>
Gerenciar Cliente
Gerenciar Hotel
Gerenci ar Acomodao
Fazer Reserva
<<extend>>
Persistir Dados
<<NF>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
Enviar Dados E-mai l
<<extend>>
183

Figura 7.6 Modelo Conceitual do Sistema de Reservas
7.3.2.J - Identificar Aspectos
A Tabela de Candidatos a Aspectos do sistema de reserva (Tabela 7.4) possui apenas trs
casos de uso: Persistir Dados, Registrar Operaes e Enviar Dados por E-mail. Como os dois
primeiro so exemplos clssicos de aspectos, os demais critrios no precisaram ser aplicados
para decidir se devem ser implementados como aspectos. J o caso de uso Enviar Dados por
E-mail funcional, atmico e no essencial ao comportamento do caso de uso Fazer
Reserva. Entretanto, mesmo com bons indcios de que sua implementao com aspectos
factvel, optou-se por postergar essa deciso para as prximas iteraes. Quatro motivos
levaram a essa deciso: o primeiro que nesta iterao, esse caso de uso estende apenas um
caso de uso base. Como outros relacionamentos podem aparecer nas prximas iteraes,
optou-se por esperar o aparecimento de novos relacionamentos algo que justificaria melhor
a implementao dele com aspectos. O segundo motivo sua simplicidade. Talvez sua
implementao com aspectos seja mais complicada e no traga benefcios suficientes. O
terceiro motivo o fato dele no caracterizar um requisito voltil. Na Tabela 7.5 mostrada a
Tabela de Aspectos para esta iterao do desenvolvimento do sistema de reservas.
Tabela 7.5 Tabela de Aspectos para o Sistema de Reservas 1 Iterao
Casos de
Uso
Tipo Atomicidade Essencialidade Volatilidade FT Implementa
como
Aspecto?
Implementado
Persistir
Dados
NF - - - S Sim
Registrar
Operaes
NF - - - S Sim
Enviar
Dados por
E-mail
F s n n N adiada
7.3.2.2. - Selecionar Aspectos para a Iterao Atual
TipoAcomodacao
descricao
preco
Cliente
nome
sobrenome
endereco
profissao
rg
cpf
t elefone
Reserva
dataIni cial
dataFi nal
numeroPessoas
1
n
1
n fei ta para um
1
1..n
1
1..n
feita-para
Acomodacao
numero
n
1
n
1
tem
Hotel
nome
endereco
estrelas
1
1..n
1
1..n
pertence a um
Endereco
1
0..1
1
0..1
tem
possui

184
Com relao ao sistema de reservas, h dois casos de uso que certamente devem ser
implementados com aspectos: Persistir Dados e Registrar Operaes. A situao do Enviar
Dados por E-mail ainda pendente. Como j havia sido previsto na atividade de
planejamento, Persistir Dados ser implementado nesta iterao em conseqncia da
necessidade de alguns conceitos persistentes para efetuar uma reserva. Alm disso, a
existncia de um FT de persistncia que pudesse ser prontamente reusado tambm colaborou
para essa deciso. J a implementao de Registrar Operaes, embora tambm haja um FT
para implement-lo, ser adiada, pois considera-se que ele poder atrasar o desenvolvimento
desta verso inicial do sistema e, alm disso, a reutilizao de dois FTs logo na primeira
iterao pode gerar algumas incompatibilidades que poderiam atrasar o projeto. Outra razo
que ele um requisito no funcional que pode ser facilmente acoplado depois que o sistema
estiver pronto. Na Tabela 7.6 mostrada a Tabela de Acompanhamento da Implementao
dos Aspectos para o sistema de reservas em questo.
Tabela 7.6 Tabela de Acompanhamento da Implementao de Aspectos para o Sistema de Reservas
No. Iterao Aspecto
1. da elaborao Persistir Dados

Como pode ser visto na Tabela 7.6, o requisito no-funcional de persistncia o nico que foi
selecionado para ser implementado nesta iterao. Como esse requisito no-funcional possui
um FT correspondente, ele no precisa ser projetado do zero, pois seu modelo de projeto pode
ser reusado, o qual pode ser visto na Figura 4.8.
Se o caso de uso selecionado para ser implementado nesta iterao no tivesse um FT
para apoiar sua implementao, ele poderia ser implementado como um aspecto normal, sem
a preocupao de generalizar seu comportamento. Outra opo implementar o caso de uso j
como um FT. Nesse caso, a arquitetura mostrada no Captulo 3 pode ser utilizada.
Uma deciso importante que deve ser tomada neste momento se o FT de persistncia
deve ser utilizado com sua variabilidade default, ou se a variabilidade escolhida deve ser a
conscincia parcial. No caso do sistema de reservas optou-se pela variabilidade default por
possuir um melhor desempenho, j que esse era um requisito do sistema.
Outro ponto importante quanto ao desempenho da aplicao. Como os requisitos do
sistema de reservas deixam claro que o desempenho da aplicao importante, interessante
que todas as caractersticas do FT de persistncia que dizem respeito a desempenho sejam
utilizadas, como, por exemplo, as caractersticas de caching e pooling. Como o acoplamento
de caractersticas j foi exemplificado no Captulo 4, no ser repetido neste captulo.
185
7.3.2.4 Acoplar Aspectos com a Base
No caso do sistema de reservas, a seqncia de reso do FT de persistncia ser a seguinte:
inicialmente a caracterstica Operaes Persistentes ser acoplada para que as operaes
bsicas de persistncia estejam disponveis durante a elaborao dos diagramas de interao.
Depois disso, os diagramas de interao sero desenvolvidos com o objetivo de descobrir
mtodos, operaes e classes de interface. Em seguida, a caracterstica Conexo poder ser
acoplada nos pontos reais, j que as classes de interface j tero sido identificadas e
projetadas.
As classes persistentes do sistema de reservas que foram identificadas para esta
iterao so: cliente, hotel, reserva, tipo de acomodao e acomodao. Na
Figura 7.7 mostrado o acoplamento do FT de persistncia mostrado apenas com duas
classes com o modelo de projeto da aplicao obtido at este momento.

Figura 7.7 Viso de Acoplamento do FT de Persistncia com o Sistema de reservas
Com esse acoplamento realizado, as classes agora esto munidas de mtodos bsicos
de persistncia que podem ser utilizados durante o projeto das outras operaes e mtodos de
negcio do sistema.
Persistence
Aplicacao
TipoAcomodacao
ID
descricao
preco
Cliente
ID
nome
sobrenome
endereco
profissao
rg
cpf
telefone
Acomodacao
ID
Reserva
ID
dataIni cial
dataFi nal
numeroPessoas
Endereco
Hotel
ID
nome
endereco
estrelas
n
1
n
1
tem
1 1..n 1 1..n
fei ta-para
1 n 1 n
faz
1 1..n 1 1..n
pertence a um
1
1..n
1
1..n
fei ta em
PersistentRoot
findAll()
findLike()
save()
setDBToObject()
...
<< interface>>
BaseClass

186
Diagramas de colaborao ou de seqncia devem ser elaborados para cada um dos
oito casos de uso alocados para esta iterao deles para que seja possvel identificar mtodos e
classes controladoras. O diagrama de colaborao mostrado na Figura 7.8 referente ao caso
de uso fazerReserva(). Note-se que o mtodo save() proveniente do FT de
persistncia, e o seu objetivo armazenar o objeto atual em algum mecanismo de persistncia.

Figura 7.8 Diagrama de Colaborao para a Operao Fazer Reserva
Como a utilizao do FT de persistncia fornece um conjunto de mtodos prontos para
as classes de aplicao persistentes, a elaborao dos diagramas de colaborao para os casos
de uso gerenciadores de dados faz pouco sentido se o objetivo for a identificao de mtodos.
Esses diagramas s sero necessrios se o objetivo for a descoberta de classes controladoras.
Entretanto, se a criao desses diagramas realmente for necessria, deve-se cuidar para que as
operaes de persistncia tenham o mesmo nome das operaes que o framework
disponibiliza.
7.3.2.S - Desenvolver Modelo de Classes de Projeto
A elaborao do modelo de classes de projeto deve ser feita com cuidado quando a deciso foi
utilizar o FT de persistncia. Isso ocorre porque seu uso impe certas restries arquitetura
do sistema e, se essas restries no forem consideradas no modelo de classes de projeto, o
acoplamento do FT de persistncia, seja neste ponto do processo ou no final, pode exigir
mudanas de projeto significativas.
Com a criao dos diagramas de colaborao e a descoberta de mtodos e outras
restries de projeto, o modelo conceitual comea a ser transformado no modelo de classes de
projeto, em que as classes agora representam tipos de uma linguagem de programao. O
reserva controladorReserva
srvFazerReserva srvFazerReserva2
hotel
hotel
1: fazerReserva()
3: getNumeroAcomodacoesDisponiveis(tipo, dataInicial, dataFinal)
10: fazerReserva()
2: verificarDisponibil idadeAcomodacao(hote, tipo, dataInicial, dataFinal)
8:
9: fazerReserva()
4: getNumeroTotalReservasNoPeriodo()
5: getNumeroTotalAcomodacoes()
6: getNumeroAcomodacoesDoTipo()
7: getNumeroReservasDoTipoNoPeriodo()
11: save()
187
modelo de classes de projeto pode ser visto na Figura 7.9, j com os mtodos que foram
descobertos por meio da elaborao dos diagramas de colaborao.

Figura 7.9 Modelo de Classes de Projeto com Classes Controladoras
7.3.2.6 - Acoplar Aspectos com a Base
Depois que os diagramas de interao foram elaborados e as classes de interface projetadas, a
segunda parte do FT de persistncia, que consiste na conexo com o banco de dados, pode ser
instanciada e acoplada ao sistema. Esta segunda parte do FT de persistncia possui a etapa de
instanciao porque algumas variabilidades precisam ser escolhidas, por exemplo, o tipo da
conexo com o banco de dados e o prprio banco que ser utilizado.
Na Figura 7.10 mostrado novamente o acoplamento entre o FT de persistncia e o
modelo de classes de projeto da aplicao, porm agora com o relacionamento de ligao
entre os pacotes. O FT de persistncia est sendo representado como um pacote vazio porque
j foi mostrado em detalhes no Captulo 4.
Embora esteja sendo mostrado apenas o relacionamento de ligao entre os pacotes,
considere-se a existncia das outras linhas de relacionamentos mostradas na Figura 7.7.
Na parte inferior da Figura 7.10 mostrado o modelo de classes de projeto do sistema
de reservas. Note-se que atributos chamados ID foram inseridos em cada uma das classes,
respeitando essa restrio que imposta pelo FT de persistncia.

ControladorReserv a
f azerReserv a()
v erif icarDisponibilidadeAcomodacao()
getReserv a()
srv FazerReserv a
init()
destroy ()
do_init()
do_destroy()
srv CadastrarCliente
(f rom Diagramas de Colaboracao) )
srv CadastrarHotel
srv CadastrarAcomodacao
srv AtualizarCliente
srv AtualizarHotel
Acomodacao
ID
TipoAcomodacao
ID
descricao
preco
n
1
n
1
tem
ControladorCadastros
clienteJaExiste()
cadastrarCliente()
hotelJaExiste()
cadastrarHotel()
tipoAcomodacaoJaExiste()
cadastrarTipoAcomodacao()
acomodacaoJaExiste()
cadastrarAcomodacao()
carregarHotel()
carregarCliente()
Cliente
ID
nome
sobrenome
endereco
prof issao
rg
cpf
telef one
Reserv a
I D
dataI ni cial
dataFinal
numeroPess oas
getNumeroReserv asDoTi poNoPeriodo()
1 1..n 1 1..n
f eita-para
1
n
1
n
f az
Hotel
ID
nome
endereco
estrelas
getNumeroTotalReserv asNoPeriodo()
f azerReserv a()
1 1..n 1 1..n
pertence a um
1
1. .n
1
1. .n
feita em
Endereco

188

Figura 7.10 Acoplamento da Parte de Conexo do FT de Persistncia com a Parte Base da Aplicao
7.3.2.7 - Desenvolver Viso da Arquitetura
Na Figura 7.11 mostrada a Viso da Arquitetura para esta primeira iterao do sistema de
reservas. O diagrama mostra que o FT de persistncia afeta estaticamente a aplicao
(Krechetov, et al., 2006).

Figura 7.11 Viso da Arquitetura 1. Iterao da Elaborao
7.3.2.8 Registrar Pontos de Juno
Na Tabela 7.7 mostrado o Registro de Pontos de Juno para o Sistema de Reservas. Como
apenas o FT de persistncia encontra-se acoplado ao sistema at este momento, no h
possibilidades de conflitos entre FTs ou aspectos.
Persistence
< AppClass.pointToOpenConnection(..)>
< AppClass.pointToCloseConnection(..)>
Aplicacao
ControladorReserv a
f azerReserv a()
getReserv a()
srv FazerReserv a
init()
destroy ()
do_init()
do_destroy()
srv CadastrarCliente
(f rom Diagramas de Colaboracao) )
srv CadastrarHotel
srv CadastrarAcomodacao
srv AtualizarCliente
srv AtualizarHotel
TipoAcomodacao
ID
descricao
preco
Cliente
ID
nome
sobrenome
endereco
prof issao
rg
cpf
telef one
clienteJaExiste()
cadastrarCliente()
hotelJaExiste()
cadastrarHotel()
carregarHotel()
carregarCliente()
Acomodacao
ID
n
1
n
1
tem
Reserv a
I D
dataI ni cial
dataFinal
numeroPess oas
getNumeroReserv asDoTi poNoPeriodo()
1 1..n 1 1..n
f eita-para
1
n
1
n
f az
Endereco
Hotel
ID
nome
endereco
estrelas
f azerReserv a()
1 1..n 1 1..n
pertence a um
1
1. .n
1
1. .n
feita em
bind [{srvFazerReserva.init(), srvCadastrarCliente.init(), srvCadastrarHotel.init()...}
{srvFazerReserva.destroy(), srvCadastrarCliente.destroy(), srvCadastrarHotel.destroy()...}
FT Persistencia
Persistent Entities
Aplicacao
<<component>> <<crosscuts>>
189
Tabela 7.7 Registro dos Pontos de Juno
FT/Aspecto
Mtodo/atributo/constructor/adendo
Classe Aspecto
FT de
Persistencia
init()
init()
init()
destroy()
destroy()
destroy()
new()
new()
new()
new()
srvFazerReserva
srvCadastrarCliente
srvCadastrarHotel
srvFazerReserva
srvCadastrarCliente
srvCadastrarHotel
Hotel
Reserva
Tipo

Os mtodos de negcio que precisam realizar armazenamentos, recuperaes e remoes no
mecanismo persistente s podero ser implementados depois que o FT de persistncia
introduzir suas operaes em cada uma das classes. Mesmo se o FT de persistncia j estiver
acoplado ao sistema, a implementao das novas classes de domnio tambm s poder ser
feita parcialmente neste ponto do processo, at que as regras de composio do FT sejam
atualizadas para considerar tambm a nova classe implementada. Os mtodos de negcio que
no precisam acessar o mecanismo persistente podem ser implementados normalmente.
Como pode ser visto na Tabela de Acompanhamento de Implementao de Aspectos (Tabela
7.6), o aspecto de persistncia o nico que deve ser implementado nesta iterao. Como h
um FT de persistncia disponvel que pode ser utilizado para apoiar a implementao desse
aspecto, o processo de implementao consiste unicamente no processo de reso desse FT.
Como comentado anteriormente, a posio desta atividade dentro da disciplina
Implementao pode variar dependendo do aspecto que est sendo implementado. Neste caso,
como a implementao de vrias operaes de negcio necessita das operaes de baixo nvel
introduzidas pelo FT de persistncia, seu acoplamento deve ser feito antes que essas
operaes de negcio sejam implementadas. por isso que esta atividade encontra-se antes da
atividade Desenvolver Classes Controladoras, pois nessa atividade que a maior parte das
operaes e mtodos de negcio implementada.
O processo de reso do FT de persistncia ser feito em dois tempos distintos,
inicialmente a caracterstica Operaes Persistentes ser acoplada s classes da aplicao para
que seja possvel implementar as operaes de sistema. Depois disso, a caracterstica Conexo
que ser acoplada para que testes possam ser conduzidos. Essa uma peculiaridade do FT
de persistncia e pode no ocorrer com outros FTs ou outras implementaes de aspectos.

190
Em relao instanciao do FT de Persistncia, como a variabilidade escolhida para
o sistema de reservas foi Conscincia Total, nada precisa ser feito j que essa a
variabilidade default desse FT.
Em relao composio com a aplicao, o aspecto MyPersistentEntities,
mostrado na Figura 7.12, elaborado com base nos valores (classes de aplicao) encontrados
na viso de acoplamento mostrada na Figura 7.10.
7.3.3.3 Desenvolver Classes Controladoras
Como o FT de persistncia j foi acoplado poro do sistema desenvolvida at o momento,
as operaes de sistema podem ser implementadas considerando a existncia das operaes de
persistncia disponibilizadas pelo framework.

Figura 7.12 Aspecto MyOORelationalMapping
Como descrito no captulo anterior, durante a realizao desta atividade pode ser
necessrio realizar adaptaes nos FTs. Foi necessrio implementar um mtodo na classe
Reserva para contar quantas reservas existem em um determinado perodo para um
determinado hotel, independentemente do tipo de acomodao. Essa adaptao pode ser vista
na Figura 4.13.
Nesta atividade, o objetivo terminar a implementao do aspecto de persistncia iniciado
anteriormente. Deve-se realizar o segundo acoplamento, pois os pontos de juno apropriados
para a abertura e fechamento da conexo com o banco de dados j foram implementados.
Em relao instanciao da caracterstica Conexo, da parte de conexo do
framework de persistncia consiste na criao de uma classe que estenda uma das classes de
variabilidades do FT de persistncia. A classe mostrada na Figura 7.13 estende a classe
OdbcConnection, indicando que a conexo ser via ODBC do Windows.
Em relao composio, o aspecto mostrado na Figura 7.14 implementado com
base no modelo mostrado na Figura 7.10. Esse aspecto considera que a classe de interface
srvFazerReserva e as classes srvCadastrarCliente e srvCadastrarHotel j
foram, pelo menos, parcialmente implementadas. Portanto, os pontos de juno identificados

declare parents: Acomodacao implements PersistentRoot;
declare parents: TipoAcomodacao implements PersistentRoot;
declare parents: Reserva implements PersistentRoot;
declare parents: Endereco implements PersistentRoot;
}
191
so os pontos reais de acoplamento, isto , os pontos de juno em que o FT permanecer
acoplado depois que o sistema estiver em produo.

Figura 7.13 Aspecto MyConnectionVariabilities

Figura 7.14 Aspecto de Acoplamento da Conexo
7.3.3.S 1estar Sistema
Foram realizados testes funcinais com o objetivo de averiguar se a poro do sistema
desenvolvida at este momento realizava um reserva, assim como foi planejado na fase de
concepo. Alm desse tipo de teste, o FT de Garantia de Polticas, uma das caractersticas do
FT de persistncia, tambm foi empregado para garantir, at certo ponto, que o acoplamento
do FT de persistncia foi feito corretamente.
7.4 IASL DL LLABORAO 2. I1LRAO
Nesta segunda iterao da fase de elaborao o objetivo evoluir a poro do sistema
desenvolvida na iterao anterior, acrescentando os casos de uso alocados especificamente
para esta iterao. Ainda h grande nfase nos requisitos, j que alguns requisitos e casos de
uso ainda no foram descobertos e registrados.
Na Figura 7.15 mostrada a viso de iterao do sistema de reserva para esta iterao.
Os casos de uso destacados em cinza so os que j foram implementados em iteraes
anteriores. Os vazios so os que ainda precisam ser implementados. Dentre os vazios ainda h
dois tipos, os marcados com um x e os que no possuem marcao. Os casos de uso
public class MyConnectionVariabilities extends OdbcConnection {

public String setSpecificDatabase(){
return "mysql";
}

public String setDSN(){
return "hotel";
}
}

public pointcut openConnection():
execution (* srvCadastrarCliente.init(..))
|| execution (* srvCadastrarHotel.init(..))
|| execution (* srvFazerReserva.init(..))
;

public pointcut closeConnection() :
execution (* srvCadastrarCliente.init(..))
|| execution (* srvCadastrarHotel.init(..))
|| execution (* srvFazerReserva.destroy(..));

return "persistenceInstantiation.MyODBCConnection";
}
}


192
marcados so os originais, isto , aqueles que foram originalmente alocados para serem
desenvolvidos nesta iterao: Gerenciar Empresas, Alterar Reserva, Ocupar Reserva e Gerar
Dados para Faturamento. Este mesmo padro representacional ser usado no restante deste
captulo.
Com o desenvolvimento dos casos de uso alocados para esta iterao pretende-se obter
uma verso do sistema que permite a ocupao de uma reserva e a gerao de uma fatura
referente estadia do cliente. Essa verso tambm deve permitir alterar os dados de uma
reserva j efetuada e cadastrar as empresas que so conveniadas com o hotel. Os casos de uso
que no possuem marcao so includos no diagrama por dois motivos: ou por que so no-
funcionais que se relacionam aos casos de uso originais, ou porque foram alocados para serem
implementados em iteraes anteriores, mas no foram. Esses ltimos devem continuar
aparecendo no diagrama at que sua situao de pendncia seja resolvida.

Figura 7.15 Viso de Iterao para a Segunda Iterao do Sistema de Reservas
A Figura geomtrica tracejada na Figura 7.15 tambm delimita visualmente os casos
de uso da primeira iterao. interessante destacar que o nmero de relacionamentos de um
caso de uso pode aumentar em relao iterao anterior. Por exemplo, o caso de uso
Enviar Dados E-mail
regi strar operaes
<<NF>>
Gerenci ar Cli ent e
Gerenci ar Hotel
Gerenciar Acomodao
Fazer Reserva
<<extend>>
<<extend>>
Gerenciar Empresas
Alterar Reserva
<<extend>>
Persistir Dados
<<NF>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrai n>>
<<constrain>>
<<constrain>>
<<constrain>>
Ocupar Reserva
<<extend>>
Aut enticar Usurio
<<NF>>
<<constrain>>
Criptografar Dados
<<NF>>
Controlar Acesso
<<NF>>
<<constrain>>
<<constrai n>>
1a. Iterao
x
x
x
x
193
Registrar Operaes possua apenas um relacionamento de extenso na iterao anterior, j
nesta iterao ele possui dois, um com o caso de uso Fazer Reserva e um outro com o caso de
uso Alterar Reserva, o qual acabou de ser acrescentado ao sistema. O caso de uso Persistir
Dados tambm possui mais trs relacionamentos de restrio comparado com a iterao
anterior, um com o Gerenciar Empresas, outro com o Alterar Reserva e outro com o Ocupar
Reserva. Isso j um indcio de que as regras de composio do FT de persistncia tero que
ser atualizadas.
Considerando a aplicao do modelo de deciso mostrado na Tabela 6.7, observou-se que os
casos de uso Ocupar Reserva e Alterar Reserva possuem um passo em comum que consiste
em identificar uma reserva com base em um cdigo que fornecido pelo hspede,
caracterizando uma funcionalidade que compartilhada por mais de um caso de uso,
respondendo sim pergunta nmero 1, o que justifica a fatorao desse caso de uso. A
segunda pergunta do modelo de deciso auxilia a identificar o tipo de relacionamento entre o
novo caso de uso e o seu criador. A resposta para esta segunda pergunta sim a
funcionalidade de identificao de reserva essencial ao comportamento do caso de uso
indicando que o relacionamento entre eles de incluso. Na Figura 7.16 mostrado o
diagrama de caso de uso para o novo caso de uso Identificar Reserva.

Figura 7.16 Viso Individual para o Caso de Uso Identificar Reserva
Prosseguindo no processo de anlise dos casos de uso, identificou-se que o caso de
uso Ocupar Reserva possui um passo que um clculo de desconto que no essencial
funcionalidade de ocupao de uma reserva, respondendo no pergunta nmero 2 do
modelo de deciso e levando criao de um novo caso de uso chamado Calcular Desconto.
O relacionamento desse novo caso de uso com o seu criador ser definido como <<extend>>.
Na Figura 7.17 mostrado o diagrama de casos de uso para a poro do sistema que
deve ser desenvolvida nesta iterao, incluindo os casos de uso colaboradores que foram
identificados. Note-se que os casos de uso colaboradores que foram identificados entram na
categoria dos originais, representados pelas elipses vazias. Est sendo feito assim porque so
Alterar Reserva
Ocupar Reserva
<<include>>
<<incl ude>>
Ident ifi car Reserva

194
oriundos dos casos de uso originais, isto , fazem parte de um comportamento que j havia
sido previsto para o sistema.

Figura 7.17 Viso de Iterao para a Segunda Iterao do Sistema de Reservas
7.4.J.2. Identificar e Registrar Casos de Uso Candidatos a Aspectos
Aplicando os critrios definidos para seleo de casos de uso candidatos a aspectos, a Tabela
de Candidatos a Aspectos deve ser atualizada (Tabela 7.8). Considerando os casos de uso do
sistema de reserva, o critrio do tipo seleciona os casos de uso Controlar Acesso e
Autenticar Usurio como candidatos a aspectos, j que os dois so no-funcionais. O critrio
quantidade de relacionamentos seleciona o caso de uso Identificar Reserva, pois includo
por dois outros casos de uso. Os critrios relacionamento de extenso e essencialidade
selecionam os casos de uso Calcular Desconto e o Gerar Dados para Faturamento e somente o
critrio de essencialidade seleciona o caso de uso Gerenciar Empresas.
Note-se que o caso de uso Calcular Desconto por si s no representa a funcionalidade
de descontos descrita pelo documento de requisitos do sistema de reservas. A descrio
textual desse requisito deixa claro que descontos so fornecidos para clientes que trabalham
em empresas conveniadas com o hotel, mostrando que o clculo de descontos especfico
Enviar Dados E-mail
regi strar operaes
<<NF>>
Gerenci ar Cli ent e
Gerenci ar Hotel
Gerenciar Acomodao
Fazer Reserva
<<extend>>
<<extend>>
Gerenciar Empresas
Alterar Reserva
<<extend>>
Persistir Dados
<<NF>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrai n>>
<<constrain>>
<<constrain>>
<<constrain>>
Ocupar Reserva
<<extend>>
Aut enticar Usurio
<<NF>>
<<constrain>>
Criptografar Dados
<<NF>>
Controlar Acesso
<<NF>>
<<constrain>>
<<constrai n>>
Calcul arDesconto
Identificar Reserva
<<include>>
<<extend>>
<<include>>
1a. Iterao
x
x
x
x
x
195
para determinadas empresas. Apesar de que o caso de uso Calcular Descontos por si s possa
ser considerado como no-essencial, j que no so todos os hotis que fornecem descontos, a
funcionalidade de descontos descrita no documento de requisitos envolve tambm o conceito
das empresas conveniadas, fazendo com que o caso de uso Gerenciar Empresas tambm faa
parte dessa funcionalidade transversal. Assim, o conceito Empresa tambm faz parte da
funcionalidade de descontos.
Tabela 7.8 Tabela de Candidatos a Aspectos
7.4.J.3 - Desenvolver Modelo Conceitual
Na Figura 7.18 mostrado o modelo conceitual para a poro do sistema tratada nesta
iterao, em que os novos conceitos esto destacados em cinza. Como o conceito Empresa
oriundo do caso de uso candidato a aspecto Gerenciar Empresa, foi destacado com uma nota.

Figura 7.18 Modelo Conceitual Atualizado
Enviar Dados por E-
mail
Controlar Acesso No-Funcional Tipo
Autenticar usurio No-Funcional Tipo
Identificar Reserva Funcional Quantidade de relacionamentos
Calcular Desconto Funcional Um relacionamento de extenso/essencialidade
Gerenciar Empresas Funcional Essencialidade
Gerar Dados para
Faturamento
Funcional Um relacionamento de extenso/essencialidade
Reserva
ID
dataInicial
dataFinal
numeroPessoas
TipoAcomodacao
descricao
preco
1
1..n
1
1..n
fei ta-para
Estada
ID
horaInicio
horaFim
1
1
1
1
origina
Acomodacao
numero
n
1
n
1
tem
1
1..n
1
1..n
envol ve uma
Endereco
Hotel
ID
nome
estrelas
1
1..n
1
1..n
pertence a um
possui
Si stemaFat uramento
gerarFatura()
<<system>>
conceito candidato a aspecto
Cl iente
ID
nome
sobrenome
endereco
profissao
rg
cpf
telefone
1 n 1 n
feita para um
1
0..1
1
0..1
tem
Empresa
nome
t elefone
tem
t em convnio
t rabalha em

196
7.4.2.J Identificar Aspectos
A Tabela de Aspectos para o sistema de reservas (Tabela 7.9) possui nesta iterao mais seis
casos de uso candidatos para serem implementados com aspectos: Controlar Acesso,
Autenticar Usurio, Identificar Reserva, Calcular Desconto, Gerenciar Empresas e Gerar
Dados para Faturamento. Na Tabela 7.9 mostrado o resultado da aplicao dos critrios para
cada caso de uso e a deciso final. Os casos de uso Controlar Acesso e Autenticar Usurios
foram considerados aspectos pela sua natureza no-funcional, alm disso, so exemplos
clssicos de aspectos encontrados na literatura. O caso de uso Identificar Reserva, apesar de
ser includo por mais de um caso de uso e ser atmico, no foi considerado um aspecto porque
essencial ao comportamento dos casos de uso base que includo. Alm disso, ele tambm
no voltil. O caso de uso Gerar Dados para Faturamento atmico, essencial
funcionalidade do caso de uso calcular reserva e no voltil, o que elimina a possibilidade
de ser implementado com aspectos.
Tabela 7.9 Tabela de Aspectos para o Sistema de Reservas 2 Iterao
Transversal
Implementa
como
Aspecto?
Implementado?
Persistir Dados NF - - S Sim
Registrar
Operaes
NF - - S Sim
Enviar Dados
por E-mail
F s N N adiada
Controlar
Acesso
NF - - S Sim
Autenticar
usurio
NF - - S Sim
Identificar
Reserva
F s n N No
Calcular
Desconto
F s s ? Sim
Gerenciar
Empresas
F s s N Sim
Gerar Dados
para
Faturamento
F s n N No

O caso de uso Calcular Desconto necessita uma anlise mais profunda. Ele atmico
porque no possvel dividir sua descrio para eliminar o compartilhamento, no essencial
ao comportamento do caso de uso base porque existem sistemas de reservas que no fornecem
descontos para empresas conveniadas, e voltil, pois os clculos e os valores de descontos
podem ser alterados a qualquer momento. O importante a ser observado que esse caso de
197
uso colaborador est atrelado ao caso de uso de gerenciamento de empresas, pois os descontos
so oferecidos apenas para as empresas que so conveniadas com o hotel.
Seguindo a linha de raciocnio do critrio da essencialidade, identifica-se que podem
haver sistemas de reservas que no fornecem descontos para empresas conveniadas. Da
mesma forma, o critrio da volatilidade tambm pode ser aplicado, pois nada garante que o
hotel fornecer esses descontos para sempre. Portanto, no apenas o caso de uso calcular
desconto que voltil e no-essencial, mas sim toda a funcionalidade de fornecimento de
descontos para empresas conveniadas, inclusive o caso de uso Gerenciar Empresas. Assim,
deve-se acompanhar com cuidado essa funcionalidade no decorrer do desenvolvimento com o
objetivo de verificar as modificaes que ela exige na poro do sistema que j est
desenvolvida e qual a estratgia de implementao que ser utilizada. Como se trata de um
requisito voltil, sua implementao deve ser feita de forma a no criar dependncias da parte
base para ela, o que facilitaria a remoo dessa funcionalidade em algum futuro prximo. Se
houver dependncias, essas devem ser implementadas de forma que o requisito voltil
dependa da parte base, e no o contrrio. Assim, como os casos de uso Calcular Descontos e o
Gerenciar Empresas possuem particularidades que justificam sua implementao com
aspectos, sero implementados com essa tecnologia.
Um ponto importante quanto existncia de FTs para apoiar a implementao desses
casos de uso. Certamente o nico FT que pode apoiar a implementao de Gerenciar
Empresas o FT de persistncia, j que esse caso de uso consiste nas operaes bsicas de
persistncia sobre o conceito Empresa. No caso de Calcular Descontos, no havia um FT que
pudesse ser utilizado para apoiar sua implementao, assim, decidiu-se por implementar um
novo FT para esse interesse voltil.
O primeiro passo foi realizar uma anlise mais profunda nesse caso de uso com o
objetivo compreender seu comportamento. Aps entrevistas com os interessados no sistema,
constatou-se que a funcionalidade de descontos deveria ser baseada em faixas de valores,
fornecendo diferentes taxas percentuais de descontos para diferentes faixas de valores gastos
no hotel, independentemente da empresa conveniada. Na Tabela 7.10 mostrada a regra dos
descontos. Se o valor da conta do cliente se enquadra em alguma das faixas, a respectiva
porcentagem mostrada na ltima coluna da tabela deduzida desse valor.
Para tornar o reso mais efetivo o primeiro passo no sentido de criar um FT para essa
regra de negcio foi generaliz-la, para que o FT pudesse ser reusado com regras de negcio
similares. Assim, a regra de negcio implementada no FT foi a seguinte: um valor x
incrementado ou decrementado em uma determinada porcentagem que depende da faixa de

198
valores que x se enquadra. Dessa forma, outras regras de negcio que utilizam a mesma
estrutura podero se beneficiar desse FT. As faixas de valores e a porcentagem so especficas
de cada regra de negcio e devem ser informadas pelo engenheiro da aplicao quando o FT
estiver sendo reusado. Esse novo FT foi denominado de Clculo Baseado em Tabela.
Outro detalhe importante que esse novo FT dependente de contexto, pois o valor
que deve ser incrementado ou decrementado deve ser capturado de um cdigo-base. Assim,
optou-se por implementar esse FT com todas as alternativas de composio do padro
Capturador de Dados. Maiores detalhes sobre esse FT podem ser encontrados na Seo 3.3.1.
Tabela 7.10 Faixas de Descontos
Limite inferior Limite superior Porcentagem de desconto
R$ 70,00 R$ 100,00 5%
R$ 101,00 R$ 200,00 7%
R$ 201,00 No existe 10%

O caso de uso Enviar Dados por E-mail, est com situao pendente, como pode ser
visto pela palavra adiada na ltima coluna da Tabela. Optou-se por manter essa pendncia e
tentar solucion-la nas outras iteraes.
Observe-se que h determinados casos de uso funcionais transversais que, caso forem
considerados aspectos, no podem ter sua implementao adiada. Por exemplo, se o caso de
uso Identificar Reserva fosse considerado um aspecto, deveria ser implementado nesta
iterao, pois uma funcionalidade necessria para se realizar uma reserva. Os casos de uso
que no sero implementados com aspectos podem ser retirados dessa tabela e tambm da
Tabela de Candidatos a Aspectos.
7.4.2.2 - Selecionar Aspectos para a Iterao Atual
Embora os casos de uso alvo desta iterao sejam quatro Controlar Acesso, Autenticar
Usurio, Calcular Desconto e Gerenciar Empresas os demais descritos na Tabela de
Aspectos, e que ainda no foram implementados, devem ser novamente analisados. Como a
quantidade de casos de uso originais desta iterao superior s demais, optou-se por no
implementar os casos de uso apoiadores, isto , aqueles que aparecem na viso de iterao
simplesmente porque possuem relacionamentos com os originais. Isso possvel porque casos
de uso apoiadores geralmente no so relacionados diretamente com a funcionalidade
principal do sistema.
Os casos de uso Controlar Acesso e Autenticar Usurio so exemplos clssicos de
requisitos adequados para serem implementados com aspectos e sua natureza permite que
sejam protelados e adicionados depois que a parte base do sistema esteja finalizada. Apesar da
existncia de FTs que podem auxiliar em sua implementao, optou-se por no sobrecarregar
199
a iterao para no extrapolar os prazos. Os casos de uso Calcular Desconto e Gerenciar
Empresas, apesar de fazerem parte da mesma funcionalidade transversal, podem ser
implementados em iteraes distintas. O caso de uso Gerenciar Empresas pode ser
implementado facilmente por que consiste nas operaes bsicas de persistncia sobre o
conceito Empresa, e a existncia do FT de persistncia auxilia nesse sentido. Entretanto, sua
implementao deve ser feita de forma a no criar dependncias da parte base para com ela.
Portanto, apenas o caso de uso Gerenciar Empresas ser implementado nesta iterao, j que
o nico original desta iterao. Na Tabela 7.11 mostrada a Tabela de Acompanhamento da
Implementao dos Aspectos para esta segunda iterao da fase de construo.
Observe-se que o requisito no-funcional de persistncia tambm pode afetar outros
requisitos transversais, como o caso do Gerenciar Empresas. A implementao desse caso
de uso, que tambm ser feita com aspectos, afetada pelo FT de persistncia.
Tabela 7.11 Tabela de Acompanhamento da Implementao de Aspectos para o Sistema de Reservas
2 Iterao
No. Iterao Aspecto
2. da elaborao Gerenciar Empresas

7.4.2.3 - Desenvolver Diagramas de Interao
Uma situao que pode ocorrer nesta atividade a necessidade de modificar um diagrama de
interao, j elaborado em iteraes anteriores, por causa da incluso de um caso de uso
selecionado como aspecto. Por exemplo, o caso de uso Gerenciar Empresas foi eleito como
aspecto e ser implementado nesta iterao. A presena desse caso de uso nesta iterao faz
com que o gerenciamento de hotis e de clientes tambm tenha que ser alterado, pois durante
o cadastro de um novo hotel precisam ser informadas as empresas conveniadas e durante o
cadastro de um cliente deve ser informada a empresa em que ele trabalha.
Como pode ser visto na Tabela de Acompanhamento da Implementao de Aspectos (Tabela
7.11) o caso de uso Gerenciar Empresas foi selecionado para ser implementado nesta iterao.
Esse caso de uso consiste nas operaes bsicas de persistncia sobre o conceito empresa,
permitindo que uma empresa seja armazenada, atualizada e ou removida do mecanismo
persistente. Como essas operaes so apoiadas pelo FT de persistncia, o projeto e a
implementao dessa parte simples e rpida. Contudo, o impacto mais significativo que esse
caso de uso traz para o sistema ocorre nas classes Hotel e Cliente, que precisam ser
modificadas com a incluso de um relacionamento com a classe Empresa, como pode ser
visto no diagrama conceitual mostrado na Figura 7.18. Isso deve ser feito porque o hotel

200
precisa saber quais so as empresas que mantm convnio com ele e um cliente necessita
informar a empresa que ele trabalha. A incluso desses relacionamentos implica em
modificaes na classe Hotel e Cliente. Na classe Hotel deve ser acrescentado um
atributo que uma lista de empresas, criar um novo construtor, e incluir dois outros mtodos
de acesso a esse atributo. Na classe Cliente deve-se tambm acrescentar um atributo do tipo
Empresa, criar um novo construtor e dois novos mtodos de acesso.
Como foi comprovado anteriormente, o caso de uso Gerenciar Empresas faz parte de
um requisito voltil que no essencial ao sistema de reservas, e por isso, no desejvel que
a parte base do sistema possua uma dependncia estrutural com a classe Empresa, ou mesmo
uma dependncia mais fraca, como a presena de um alguns mtodos que referenciem essa
classe. Alm dessa modificao na parte base do sistema, a classe controladora de cadastros
tambm deve ser modificada com o acrscimo de outros mtodos relativos classe Empresa,
tambm criando dependncias indesejadas. Portanto, o relacionamento existente entre essas
classes, e inclusive a insero de novos mtodos, deve ser feito de forma transparente para a
parte base do sistema, sem que essa fique dependente da classe Empresa. Uma das formas de
incluir esses relacionamentos e esses mtodos nas classes Hotel e Cliente por meio de
declaraes intertipo da linguagem AspectJ.
Na Figura 7.19 mostrado o projeto do caso de uso Gerenciar Empresas como um
tema-base. A classe Hotel apresentada com dois novos mtodos de acesso a atributos, um
novo construtor e um novo relacionamento com a classe Empresa. A classe Cliente, da
mesma forma, possui um relacionamento de associao com a classe Empresa, um novo
construtor e dois novos mtodos de acesso a atributos. Quando esse modelo for composto por
intercalao com a parte base da aplicao, as classes com o mesmo nome sero agrupadas
em apenas uma, e os mtodos e relacionamentos que esto projetados, e que no existem nas
classes correspondentes, sero includos nelas.
7.4.2.S Desenvolver Modelo de Classes de Projeto
A elaborao dos diagramas de colaborao mostrados na atividade anterior auxilia na
identificao de novas operaes, mtodos e classes que devem ser adicionadas no diagrama
de classes de projeto. Assim, na Figura 7.20 mostrado parcialmente o diagrama de classes
de projeto atualizado do sistema de reservas. Deve ser observado que esse modelo de classes
o modelo que j foi composto com o FT de persistncia em momentos anteriores, porm toda
parte relativa ao FT de persistncia no est sendo exibida para melhorar a legibilidade. As
classes atualizadas com a insero de novos mtodos foram Hotel, ControladorReserva
e Acomodacao. Note-se tambm a adio das classes Estada e srvOcuparReserva, e do
201
sistema de faturamento SistemaFaturamento. A classe ControladorCadastros no
est sendo exibida com todos os seus relacionamentos para facilitar a visualizao.

Figura 7.19 Projeto do Aspecto Funcional Gerenciar Empresas

Figura 7.20 Modelo de Classes de Projeto para o Sistema de Reservas 2. Iterao
7.4.3 - Projetar Acoplamento dos Aspectos com a Base
Como o nico aspecto funcional do sistema de reservas foi projetado como um tema-base, a
composio entre a poro j projetada da aplicao com esse tema-base feita por meio de
um relacionamento de intercalao. Assim, os elementos que possuem os mesmos nomes so
agrupados em apenas um.
Empresa
Hotel
new()
setEmpresa()
getEmpresa()
Endereco
cadastrarEmpresa()
empresaJaExiste()
cadastrarHotel()
cadastrarCliente()
Cliente
new()
getEmpresa()
setEmpresa()
Empresa
ID
nome
telefone
setID()
getID()
setNome()
getNome()
setEndereco()
getEndereco()
setTelefone()
getTelefone()
0. .n 1..n 0. .n 1..n
possui convnio com
1
1
1
1
tem
1
1..n
trabalha em
1
1..n
ControladorReserv a
f azerReserv a()
ocuparReserv a(IDReserv a : Integer)
ocuparReserv a(nomeCliente)
alterarReserv a()
getReserv a()
criarEstadia()
srv OcuparReserv a
ini t()
do_init()
des tr oy ()
do_destroy ()
clienteJaExiste()
cadastrarCliente()
hotelJaExiste()
cadastrarHotel()
carregarHotel()
carregarCliente()
TipoAcomodacao
descricao
preco
Estada
ID
horaInicio
horaFim
Cliente
ID
nome
sobrenome
endereco
prof issao
rg
cpf
telef one
Acomodacao
numero
getNumeroAcomodacoesDoTipo(tipoAcomodacao)
getAcomodacaoDisponiv elDoTipo( )
n
1
n
1
tem
1
0..1
1
0..1
Reserv a
ID
dataInicial
dataFinal
numeroPessoas
getNumeroReserv asDoTipoNoPeriodo()
1
1..n
1
1..n
f eita-para 1 n 1 n
f eita para um
Endereco
Hot el
ID
nome
estrelas
f azerReserv a()
ocuparReserv a(IDReserv a)
ocuparReserv a(cliente)
alterarReserv a()
identif icarReserv a(IDReserv a)
identif icarReserv a(cliente)
1 1..n 1 1..n
pert ence a um
1
1..n
1
1..n
feita em
SistemaFaturamento
gerarFatura()
<<sy stem>>
Aplicao

202
Na Figura 7.21 mostrada a composio entre os temas Aplicao Base e Empresa e a
Figura 7.22 mostra o tema resultante dessa composio. Note-se o aparecimento da classe
Empresa, seus relacionamentos com a classe Hotel, Endereco e
ControladorCadastros e dois novos mtodos na classe ControladorCadastros, o
cadastrarEmpresa() e o empresaJaExiste().

Figura 7.21 Composio entre Temas Base

Figura 7.22 Tema resultante da composio Modelo de Classes de Projeto 2a. Iterao

Aplicacao Base
ControladorReserv a
f azerReserv a()
oc uparReserv a(IDReserv a : Integer)
oc uparReserv a(nomeCliente)
alt erarReserv a()
getReserv a()
criarEs tadia()
srv OcuparReserv a
init()
do_init ()
des troy ()
do_dest roy ()
ControladorCadast ros
c lient eJaExis te()
c adast rarCliente()
hotelJaExiste()
c adast rarHot el()
t ipoAcomodacaoJ aExist e()
c adast rarTipoAcomodac ao()
acomodac aoJaEx is te()
c adast rarAcomodacao()
c arregarHot el()
c arregarCliente()
TipoAc omodacao
desc ricao
preco
Es tada
I D
horaInicio
horaFim
Cliente
ID
nome
sobrenome
endereco
prof issao
rg
cpf
telef one
Acomodacao
numero
get NumeroAcomodac oesDoTipo(t ipoAcomodacao)
get AcomodacaoDisponiv elDoTipo()
n
1
n
1
t em
1
0. .1
1
0. .1
Res erv a
ID
dat aInicial
dat aFinal
numeroPessoas
get NumeroRes erv asDoTipoNoPeriodo()
1 1. .n 1 1. .n
f eit a-para 1 n 1 n
f eita para um
Enderec o
Hot el
I D
nome
estrelas
f azerReserv a()
alt erarRes erv a()
1 1. .n 1 1. .n
pert ence a um
1
1. .n
1
1. .n
feit a em
SistemaFaturament o
gerarFat ura()
<<s y stem>>
Empresa
Hotel
new()
setEmpresa()
getEmpresa()
Endereco
cadastrarEmpresa()
empresaJaExiste()
Cliente
new()
getEmpresa()
setEmpresa()
Empresa
ID
nome
telefone
setID()
getID()
setNome()
getNome()
setEndereco()
getEndereco()
setTelefone()
getTelefone()
0..n 1. .n 0..n 1. .n
possui convnio com
1
1
1
1
t em
1
1..n
trabalha em
1
1..n
ThemeName[Aplicacao]
match[name]
Aplicacao
ControladorReserv a
f azerReserv a()
ocuparReserv a(IDReserv a : Integer)
ocuparReserv a(nomeCliente)
alterarReserv a()
getReserv a()
criarEstadia()
srv OcuparReserv a
init()
do_init()
destroy ()
do_destroy ()
clienteJaExiste()
cadastrarCliente()
hotelJaExiste()
cadastrarHotel()
carregarHotel()
carregarCliente()
cadastrarEmpresa()
empresaJaExiste()
SistemaFaturamento
gerarFatura()
<<sy stem>>
TipoAcomodacao
descricao
preco
Estada
ID
horaInicio
horaFim
Acomodacao
numero
getNumeroAcomodacoesDoTipo(tipoAcomodacao)
getAcomodacaoDisponiv elDoTipo( )
n
1
n
1
tem
1
0..1
1
0..1
Reserv a
ID
dataInicial
dataFinal
numeroPessoas
getNumeroReserv asDoTipoNoPeriodo( )
1
1..n
1
1..n
f eita-para
Cliente
ID
nome
sobrenome
endereco
prof issao
rg
cpf
telef one
1 n 1 n
f eita para um
Hot el
ID
nome
estrelas
f azerReserv a()
alterarReserv a()
1 1..n 1 1..n
pertence a um
1
1..n
1
1..n
feita em
Endereco
Empresa
nome
tel efone
203
7.4.2.7 Desenvolver Viso da Arquitetura
Esta atividade tem como objetivo desenvolver ou evoluir a Viso da Arquitetura do Sistema.
Ela sempre deve ser realizada aps o acoplamento de algum FT ou aspecto ao sistema. Como
a atividade anterior projetou e acoplou o aspecto Empresa ao sistema, a Viso da Arquitetura
deve ser atualizada como mostra a Figura 7.23. Note-se que o relacionamento de entrecorte
entre esse aspecto e o componente-base esttico.

Figura 7.23 Viso da Arquitetura 2. Iterao da Elaborao
7.4.2.8 Registrar Pontos de Juno
Como o novo aspecto includo no sistema realiza apenas modificaes estticas no ser
necessrio registr-lo no Registro de Pontos de Juno.
Nesta iterao, as classes Estada, Empresa e srvOcuparReserva foram adicionadas ao
modelo de classes de projeto. A classe Estada e a classe Empresa so classes persistentes
porque possuem tabelas correspondentes no banco de dados e a classe srvOcuparReserva
uma classe de interface, em que a conexo com o banco de dados deve ser aberta e fechada.
Portanto, as regras de composio devem ser atualizadas para que o FT de persistncia
tambm afete esses novos elementos de projeto.
Na Figura 7.24 mostrada a atualizao realizada nas regras de composio, as quais
esto destacadas em negrito. A primeira operao gabarito agora tambm considera o mtodo
init() da classe srvOcuparReserva. A segunda operao gabarito, responsvel pelo
encerramento da conexo com o banco de dados agora considera o mtodo destroy(),
tambm da classe srvOcuparReserva e, por ltimo, a terceira operao gabarito considera
o construtor da classe Estada, e o construtor da classe Empresa. Embora essas classes no
estejam sendo exibidas considere sua existncia dentro do pacote.
Como comentado anteriormente, sempre que as regras de composio de um FT que j
foi acoplado ao sistema so atualizadas, deve-se tambm atualizar o Registro de Pontos de
Juno e analisar se h pontos de juno compartilhados por dois ou mais aspectos/FTs.
Sendo assim, a Tabela 7.12 mostra o Registro de Pontos de Juno atualizado para o sistema
FT Persistencia
Persistent Ent it ies
Empresa
NewInterface
Aplicacao
<<crosscuts>>

204
de reservas. Como apenas o FT de persistncia encontra-se acoplado ao sistema, no h
pontos de juno afetados por dois ou mais FTs.

Figura 7.24 Viso de Acoplamento para o Sistema de Reservas 2. Iterao da Elaborao

Tabela 7.12 Registro de Pontos de Juno 2. Iterao da Elaborao
FT/Aspecto
Classe Aspecto
FT de
Persistencia
init()
init()
init()
init()
destroy()
destroy()
destroy()
destroy()
new()
new()
new()
new()
new()
new()
srvOcuparReserva
srvFazerReserva
srvCadastrarCliente
srvOcuparReserva
srvCadastrarHotel
srvFazerReserva
srvCadastrarCliente
srvCadastrarHotel
Hotel
Reserva
Tipo
Estada
Empresa

As classes do sistema de reservas que devem ser implementadas nesta iterao so Estada,
Empresa e srvOcuparReserva. Embora a classe Empresa esteja relacionada a um
requisito voltil, sua implementao pode ser feita com tcnicas orientadas a objetos. O que
precisa ser analisado com cuidado o seu relacionamento com as demais classes da parte base
do sistema, por exemplo com a classe Hotel e com a classe Cliente. Como comentado na
fase de projeto, no desejvel que as classes Hotel e Cliente tenham dependncias
estruturais com a classe Empresa, j que esta oriunda de um requisito voltil. Portanto,
optou-se por implementar os relacionamentos e toda funcionalidade existente entre essas
Persistence
Aplicacao
bind [{srvFazerReserva.init(), srvCadastrarCliente.init(), srvCadastrarHotel.init(),
srvOcuparReserva.init()...}
{srvFazerReserva.destroy(), srvCadastrarCliente.destroy(), srvCadastrarHotel.destroy(),
srvOcuparReserva.destroy()...}
205
classes utilizando as declaraes intertipo da linguagem AspectJ. Dessa forma, no haver
dependncias em tempo de projeto.
Na Figura 7.25 mostrado o aspecto EmpresasConveniadas. Esse aspecto introduz
atributos e mtodos nas classes Hotel, Cliente e ControladorCadastros, referentes ao
requisito voltil em questo. Na classe Hotel, introduzido um atributo chamado empresa
do tipo vetor, que representa o relacionamento estrutural entre essas duas classes. Assim, a
classe Hotel torna-se inconsciente da presena desse atributo e possui dependncia com o
requisito voltil apenas em tempo de execuo. Esse aspecto introduz tambm na classe
Hotel os mtodos de acesso ao atributo introduzido setEmpresa() e getEmpresa() e
um novo construtor, o qual considera o novo atributo com um parmetro. Na classe Cliente
so introduzidos um atributo do tipo Empresa, que representa o relacionamento de
associao entre essas classes, um novo construtor e dois novos mtodos de acesso a
atributos. Alm dessas introdues, os mtodos cadastrarEmpresa() ,
cadastrarHotel() e cadastrarCliente() tambm so introduzido na classe
controladora ControladorCadastros.

Figura 7.25 Aspecto EmpresasConveniadas
No caso do sistema de reservas, deve-se apenas atualizar o acoplamento do FT de persistncia
com as novas classes criadas nesta iterao: Empresa e Estada. O aspecto
MyPersistentEntities deve ser atualizado para que essas duas classes tambm possam
ter as operaes de persistncia introduzidas, como mostra a Figura 7.26.
public aspect EmpresasConveniadas {

private Vector Hotel.empresa;
private Empresa Cliente.empresa;

public void Hotel.setEmpresa(Vector empresa){...}

public void Cliente.setEmpresa(Empresa empresa){...}

public Vector Hotel.getEmpresa(){...}

public Empresa Cliente.getEmpresa(){...}

public static Hotel ControladorCadastros.cadastrarHotel(...){...}

public static Cliente ControladorCadastros.cadastrarCliente(...){...}

Cliente cliente = new Cliente(...){...}

public static boolean ControladorCadastros.empresaJaExiste(...){...}

public static Empresa ControladorCadastros.cadastrarEmpresa(...){...}

public Hotel.new(...){...}

public Cliente.new(...){...}
}

206

Figura 7.26 Atualizao do Aspecto MyPersistentEntities
Atualizaes tambm so necessrias na conexo com o banco de dados, j que novas
classes de interface agora esto presentes no sistema. Na Figura 7.27 mostrada a atualizao
realizada em negrito.

Figura 7.27 Atualizao das Regras de Composio da Conexo
7.4.3.3 1estar Sistema
Analisando a Viso de Arquitetura pde-se constatar que o nico aspecto adicionado ao
sistema nesta iterao foi Empresa. Sendo assim, foram realizados testes funcionais com o
objetivo de verificar se as funcionalidades que envolviam o conceito Empresa estavam
funcionando corretamente.
Como as regras de composio do FT de Persistncia tambm tiveram que ser
atualizadas em virtude da adio do caso de uso Gerenciar Empresa nesta iterao, suas
funcionalidades tambm foram testadas novamente.
7.S IASL DL CONS1RUAO J I1LRAO
Na Figura 7.28 mostrada a viso de iterao de casos de uso para o sistema de
reservas. Os casos de uso alocados originalmente para esta iterao so os vazios marcados
com um x, isto , Cancelar Reserva e No Comparecer. Os casos de uso vazios sem
marcao so os que ainda no esto implementados e que possuem situao pendente, isto ,
sua implementao foi postergada para iteraes futuras. Geralmente so casos de uso no-

...
declare parents: Empresa implements PeristentRoot;
declare parents: Estada implements PersistentRoot;

public pointcut openConnection(): execution (*
srvCadastro*.init(..))
|| execution (* srvFazerReserva.init(..))
|| execution (* srvAlterarReserva.init(..))
|| execution (* srvOcuparReserva.init(..))
|| execution (* srvCadastroHoteis.init(..);

public pointcut closeConnection() : execution (*
srvCadastro*.destroy(..))
|| execution (* srvFazerReserva.destroy(..))
|| execution (* srvAlterarReserva.destroy(..))
|| execution (* srvOcuparReserva.destroy(..))
|| execution (* srvCadastroHoteis.destroy(..);
...
}
207
funcionais que foram acrescentados ao sistema em conseqncia de um relacionamento que
mantinham com algum caso de uso alocado para a iterao. Os casos de uso destacados em
cinza so os que j esto implementados. Nenhum caso de uso no-funcional foi adicionado
nesta iterao.

Figura 7.28 Viso de Casos de Uso da Iterao Atual 1. Iterao da Construo
Na Figura 7.28 tambm so mostrados alguns novos relacionamentos que surgiram em
decorrncia da incluso dos dois casos de uso alocados para esta iterao. O caso de uso No
Comparecer restringido pelos casos de uso Autenticar Usurio, Controlar Acesso e Persistir
Dados. O caso de uso Cancelar Reserva restringido pelo caso de uso Persistir Dados e
estendido por Registrar Operaes. Esses novos relacionamentos so facilmente identificados
porque na fase de concepo foram elaborados diagramas de casos de uso para cada requisito
no-funcional. Nessa mesma figura tambm possvel identificar os casos de uso originais da
primeira e segunda iteraes da elaborao e da iterao atual, os quais esto delimitados por
figuras geomtricas tracejadas.
Regist rar Operaes
<<NF>>
Identificar Reserva
Calcul arDesconto
Controlar Acesso
<<NF>>
Gerenciar Cli ente
Gerenciar Hotel
Gerenciar Acomodao
Fazer Reserva
<<extend>>
<<extend>>
Gerenciar Empresas
Alterar Reserva
<<include>>
<<extend>>
Cancelar Reserva
<<extend>>
Ocupar Reserva
<<include>>
<<extend>>
<<extend>>
<<constrain>>
No Comparecer
<<constrain>>
Persistir Dados
<<NF>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
Criptografar Dados
<<NF>>
Autenticar Usurio
<<NF>>
<<constrain>>
<<constrain>>
<<constrain>>
1
a
. Iterao
Iterao
Atual
x
x
2
a
. Iterao

208
Como nesta iterao no houve a identificao e implementao de nenhum aspecto,
apenas as disciplinas de Anlise e Projeto sero comentadas resumidamente. A disciplina de
Implementao ser suprimida.
7.S.J Disciplina Anlise
Na atividade Identificar e Registrar Casos de Uso Colaboradores, nenhum novo caso de uso
foi identificado. Apenas foram acrescentados alguns relacionamentos entre alguns casos de
uso.
Na atividade Identificar e Registrar Casos de Uso Candidatos a Aspectos, nenhum
novo caso de uso candidato a aspecto foi identificado para esta iterao. Portanto, a Tabela de
Candidatos a Aspectos (Tabela 7.8) permanece a mesma da iterao anterior, a nica
diferena que o caso de uso Gerenciar Empresas deve ser marcado como implementado.
Durante a atividade Desenvolver Modelo Conceitual nenhuma tarefa foi necessria
porque todos os conceitos utilizados pelos casos de uso Cancelar Reserva e No Comparecer
j se encontram no modelo conceitual, nenhuma atualizao foi necessria.
7.S.2 Disciplina Projeto
Na atividade Identificar Aspectos, a Tabela de Aspectos (Tabela 7.9) tambm permanece a
mesma da iterao anterior, j que no h novos casos de uso transversais nesta iterao.
Durante a realizao da atividade Selecionar Aspectos para a Iterao Atual, optou-se
por continuar postergando a implementao dos aspectos listados na Tabela de Aspectos
(Tabela 7.9) para o final. Isso foi possvel porque em geral, os aspectos que esto na Tabela
de Aspectos so no-funcionais ou so funcionais que no influenciam diretamente na
funcionalidade principal do sistema.
A atividade Desenvolver Diagramas de Interao foi conduzida de forma
convencional resultando em dois diagramas de seqncia: um para o caso de uso Cancelar
Reserva e outro para o caso de uso No Comparecer.
Na atividade Desenvolver Modelo de Classes de Projeto o objetivo evoluir o modelo
de classes de projeto desenvolvido at o momento com base nos diagramas de interao
elaborados na atividade anterior. Na Figura 7.29 mostrado o modelo de classes de projeto
atualizado do sistema de reservas. A classe controladora dos cadastros e algumas outras
relacionadas no esto sendo exibidas para melhorar a visualizao e tambm porque no
sofreram modificaes em relao verso anterior. As classes que evoluram nesta iterao
foram: ControladorReserva, Reserva e SistemaFaturamento. Na classe
ControladorReserva, por exemplo, foram acrescentados os mtodos
209
cancelarReserva(), getReservasVencidasHoje() e
identificarReservasNaoOcupadas().

Figura 7.29 Modelo de Classes de Projeto para o Sistema de Reservas 1a. Iterao da Construo
Na atividade Atualizar Regras de Composio, o FT de persistncia deve ter suas
regras atualizadas. Como no houve o aparecimento de nenhuma nova classe persistente de
aplicao nesta iterao, no h a necessidade de atualizar as regras referentes parte bsica
de persistncia, isto , a caracterstica Operaes Persistentes. Apenas a parte relativa
conexo com o banco de dados que deve ser atualizada, pois duas novas classes de interface
foram adicionadas no sistema nesta iterao: srvFaturarReservasNaoOcupadas e
srvCancelarReserva. Na Figura 7.30 so mostradas em negrito as atualizaes realizadas.
Na Tabela 7.13 mostrado parcialmente o Registro de Pontos de Juno para a
primeira iterao da construo. Como apenas o FT de Persistncia encontra-se acoplado ao
sistema, no h dois ou mais FTs que atuam em pontos de juno comuns.
7.6 IASL DL CONS1RUO 2. I1LRAO
Na Figura 7.31 mostrada a viso de iterao do sistema de reservas para esta segunda
iterao da construo. Alguns casos de uso que j foram implementados no esto sendo
mostrados para facilitar a visualizao. Alguns continuam sendo exibidos porque possuem
Cont roladorReserv a
f azerReserv a()
ocuparReserv a(I DReserv a : I nt eger)
ocuparReserv a(nomeClient e)
alt erarReserv a()
get Reserv a()
criarEst adia()
ident if icarReserv asNaoOcupadas()
get Reserv asVencidasHoje()
ident if icarReserv a()
cancelarReserv a()
TipoAcomodacao
I D
des cricao
preco
Est ada
I D
horaI ni cio
horaFim
f indlik e()
Client e
I D
no me
so bren ome
en dere co
prof issao
r g
cp f
t el ef one
Acomodacao
I D
get NumeroAcomodacoesDoTipo(t ipoAcomodacao)
get AcomodacaoDispo niv elDoTipo()
n
1
n
1
t em
1
0. . 1
1
0. . 1
Reserv a
f azerReserv a()
gerouEst adia()
get NumeroReserv asDoTipoNoPeriodo()
get NumeroReserv asNoPeriodo()()
1
1. . n
1
1. . n
f eit a-para
1
n
1
n
f a z
Empresa
I D
nome
Endereco
Hot el
get NumeroTot alReserv asNoPeriodo()
f azerReserv a()
ocuparReserv a(I DReserv a)
ocuparReserv a(client e)
alt erarReserv a()
ident if icarReserv a(I DReserv a)
ident if icarReserv a(client e)
get NumeroAcomodacoesDisponiv eis()
get NumeroTot alAcomodacoes()
get NumeroAcomodacoesDoTipo()
get NumeroReserv asDoTipoNoPeriodo()
1 1. . n 1 1. . n
pert ence a um
1
1. . n
1
1. . n
f eit a em
1. . n
1. . n
1. . n
1. . n
t em co nvnio
srv CancelarReserv a
srv Fat u rar Reserv a sN aoO cupada s
Sist emaF at urament o
gerarFat ura()
gerarFat uraReserv aVencida(reserv a)()

210
relacionamentos importantes com casos de uso que ainda no foram implementados. Os casos
de uso marcados com um x so os originais da iterao, os vazios sem marcao so os que
ainda no foram implementados oriundos de iteraes anteriores e os cinza so os que j
foram implementados. Os casos de uso alocados para esta iterao so: Reajustar Valor das
Dirias, Consultar Nmero de Reservas, Listar Reservas por Perodo e Gerenciar Usurios.

Figura 7.30 Atualizao das Regras de Composio 1. Iterao da Construo
Tabela 7.13 Registro de Pontos de Juno 1a. Iterao da Construo
FT/Aspecto
Classe Aspecto
FT de
Persistencia
init()
init()
destroy()
destroy()
srvCadastrarCliente
srvOcuparReserva
srvCancelarReserva
srvFaturarReservasNaoOcupadas

7.6.J..J Identificar e Registrar Casos de Uso Candidatos a Aspectos
Na Tabela de Candidatos a Aspectos para esta iterao (Tabela 7.14) mostrado que apenas o
caso de uso Gerenciar Usurio foi selecionado como candidato a aspectos. O caso de uso
Gerenciar Usurios foi selecionado pelo critrio Tipo porque sua funcionalidade parte do
interesse no-funcional de controle de acesso, que um exemplo clssico da literatura sobre
aspectos.
Os outros casos de uso selecionados para esta iterao no so candidatos a aspetos
porque so funcionais, no so volteis e consistem em operaes bsicas de consulta ou
relatrios do sistema cuja implementao no se torna espalhada por vrios mdulos.
7.6.2.J Identificar Aspectos
Aplicando os critrios especficos desta atividade, o caso de uso Gerenciar Usurios foi
identificado como aspecto porque sua funcionalidade parte do caso de uso Controlar
Acesso. Um ponto importante reavaliar os casos de uso que possuem situao pendente com
Persistence
Aplicacao
srvOcuparReserva.init(), srvCancelarReserva.init(),
srvFaturarReservasNaoOcupadas.init()...}
srvOcuparReserva.destroy(), srvCancelarReserva.destroy(),
srvFaturarReservasNaoOcupadas.destroy(..)...}

211
o objetivo de averiguar se devem ser implementados com aspectos ou no. Na Tabela 7.15
mostrado que o caso de uso Enviar Dados por E-mail ainda est com situao pendente, pois
possui a palavra adiada na coluna Implementa como aspecto?. Isso mostra que nas
iteraes anteriores no havia informao suficiente sobre esse caso de uso que pudesse
embasar a deciso de implement-lo com ou sem aspectos. Como o processo agora est em
sua ltima iterao da fase de construo, h mais conhecimento sobre o sistema e uma
deciso pode ser tomada com mais certeza. Na Figura 7.5 mostrado que o caso de uso
Enviar Dados por E-mail estende apenas um caso de uso e, como no haver mais adio de
casos de uso funcionais ao sistema, o nmero de relacionamentos que esse caso de uso possui
provavelmente no aumentar, caracterizando-o como uma funcionalidade restrita e pontual
dentro do sistema. Alm disso, um estudo das formas possveis de implementao dessa
funcionalidade revelou que seria possvel alcanar bons nveis de modularidade mesmo com
orientao a objetos, isto , toda a funcionalidade poderia ser implementada com uma ou duas
classes e uma nica operao disponibilizada para o cdigo cliente. Em conseqncia disso,
optou-se por no implementar esse caso de uso com aspectos. Dessa forma, deve-se projetar
esse caso de uso normalmente com orientao a objetos e atualizar os modelos que ele
influencia.

Figura 7.31 Viso de Iterao para o Sistema de Reservas 2. Iterao da Construo
CalcularDesconto
Controlar Acesso
<<NF>>
Registrar Operaes
<<NF>>
List ar Reservas por Periodo
<<constrain>>
Consul tar Numero de Reservas
<<constrai n>>
Reajustar Valor das Diarias
<<constrain>>
No Comparecer
<<extend>>
<<constrain>>
Ocupar Reserva
<<extend>>
<<constrain>>
Gerenci ar Usuarios
<<constrain>>
Fazer Reserva
<<extend>>
<<extend>>
Alterar Reserva
<<extend>>
Persistir Dados
<<NF>>
<<constrain>> <<constrain>>
Criptografar Dados
<<NF>>
Autenticar Usurio
<<NF>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrai n>>
x
x
x
x

212
Tabela 7.14 Tabela de Candidatos a Aspectos
Tabela 7.15 Tabela de Aspectos para o Sistema de Reservas 2a. Iterao da Construo
Transversal
Implementa
como
Aspecto?
Implementado?
Persistir
Dados
NF - - S Sim
Registrar
Operaes
NF - - S Sim
Enviar Dados
por E-mail
F s N N Adiada
Controlar
Acesso
NF - - S Sim
Autenticar
usurio
NF - - S Sim
Calcular
Desconto
F s s S Sim
Gerenciar
Empresas
F s s N sim
Gerenciar
Usurios
NF s n S sim

Depois que um caso de uso deixa o estado de pendncia, deve-se ainda decidir quando
ele deve ser implementado se na iterao atual ou em alguma outra iterao futura. Em
geral, casos de uso que se encontram em situao pendente no so primordiais
funcionalidade central do sistema, caso contrrio teriam sido implementados nas iteraes
iniciais. No caso do Enviar Dados por E-mail, decidiu-se implement-lo na iterao atual por
esta ser a ltima iterao da fase de construo. Assim, os artefatos devem ser atualizados
para considerarem tambm esse novo caso de uso.
7.6.2.2 Selecionar Aspectos para a Iterao Atual
O Gerenciar Usurio o nico aspecto introduzido nesta iterao. Como ele parte integrante
do caso de uso Controlar Acesso, optou-se por postergar sua implementao de forma que
esses dois casos de uso sejam implementados juntos. Assim, optou-se por no implementar
nenhum aspecto nesta iterao, fazendo com que a Tabela de Acompanhamento da
Implementao dos Aspectos continue sem modificaes, como mostrado na Tabela 7.16.

Enviar Dados por E-
mail
Controlar Acesso No-Funcional Tipo
Autenticar usurio No-Funcional Tipo
Gerenciar Empresas Funcional Essencialidade
Calcular Desconto Funcional Um relacionamento de extenso/essencialidade
Gerenciar Usurios No-funcional Tipo
213
Tabela 7.16 Tabela de Acompanhamento da Implementao dos Aspectos
No. Iterao Aspecto
2. da elaborao Gerenciar Empresas
7.6.2.3 Desenvolver Diagramas de Interao
Durante a elaborao do diagrama de seqncia do caso de uso Reajustar Valor das Dirias
notou-se que esse caso de uso deveria apresentar mais detalhes para ser compreendido
adequadamente. A descrio desse caso de uso, como pode ser vista na Figura 7.32, revela na
segunda linha que o sistema deve apresentar as opes de reajuste existentes, mas no diz
nada sobre quais so essas opes de reajuste. Consultando os especialistas e pessoas
interessadas no sistema, identificou-se que seria conveniente a existncia de dois tipos de
reajuste: reajuste com valores fixos e reajuste com valores percentuais. Alm desses dos tipos,
tambm seria conveniente se houvesse trs estratgias de reajuste, uma que pudesse ser
utilizada para reajustar todos os tipos de acomodao de uma nica vez, outra em que o
reajuste pudesse ser feito para tipos de acomodao escolhidos e outra que, alm de poder
escolher os tipos de acomodao, que tambm pudesse escolher um tipo de reajuste diferente
para cada tipo de acomodao, por exemplo, valor fixo para quartos de Luxo e porcentagem
para quartos Simples. Os tipos e as estratgias de reajuste podem variar freqentemente, o que
caracteriza esse requisito como voltil.

Figura 7.32 Caso de Uso Reajustar Valor das Dirias
Quando uma determinada funcionalidade percebida como voltil ou candidata a
aspectos, a Tabela de Aspectos deve ser atualizada e os critrios devem ser aplicados com o
objetivo de decidir se a nova funcionalidade deve ser implementada com aspectos. Na Tabela
7.17 mostrada a Tabela de Aspectos atualizada para o sistema de reservas. Se as novas
funcionalidades forem casos de uso, elas podem ser listadas juntamente com os casos de uso
j presentes na tabela. Se forem funcionalidades menores, aconselha-se dar um nome para
identific-las e list-las em uma parte separada da tabela, chamada Funcionalidades Extras.
Nome: Reajustar o Valor de Dirias
Ator Principal: Gerente do Hotel
Objetivo: Reajustar o valor das dirias
Nmero no Documento de Requisitos: 15

1. O gerente do hotel deseja reajustar o valor de dirias.
2. O sistema apresenta as opes de reajuste existentes.
3. O gerente escolhe a opo de reajuste
4. O sistema solicita a forma como a diria deve ser reajustada
5. O gerente informa o tipo de reajuste desejado e o valor
6. O gerente confirma o reajuste


214
No caso em questo, a funcionalidade foi nomeada como Estratgias e Tipos de Reajuste e a
tabela mostra o resultado da aplicao dos critrios. Essa funcionalidade funcional, atmica
(pois no pode ser dividida em dois ou mais comportamentos distintos) e voltil. Assim,
optou-se por implementar esse caso de uso com aspectos. Entretanto, como no havia FT para
apoiar a implementao desse caso de uso, optou-se por desenvolver um.
Tabela 7.17 Tabela de Aspectos para o Sistema de Reservas
Casos de Uso Tipo Atomicidade Volatilidade FT Implementa
como Aspecto?
Implementado?
Persistir
Dados
NF - - S Sim
Registrar
Operaes
NF - - S Sim
Enviar Dados
por E-mail
F s N N adiada
Controlar
Acesso
NF - - S Sim
Autenticar
usurio
NF - - S Sim
Calcular
Desconto
F s s S Sim
Gerenciar
Empresas
F s s N sim
Gerenciar
Usurios
NF s n S sim
Funcionalidades Extra
Nome
Estratgias e
Tipos de
Reajuste
F s s S Sim

Assim como o FT de Persistncia, Reajustar Valor das Dirias uma funcionalidade
que deve disponibilizar determinadas operaes para o cdigo-base utilizar. Algum usurio do
sistema que deve decidir quando que determinado reajuste deve ser aplicado para as
dirias do hotel. Assim, essas operaes devem poder ser acessadas pela interface grfica do
sistema.
Depois que o processo de deciso foi realizado, deve-se ainda decidir se a nova
funcionalidade deve ser implementada nesta iterao ou postergada para iteraes futuras.
Sendo assim, a atividade Selecionar Aspectos para a Iterao Atual deve ser realizada
novamente com o objetivo de realizar essa deciso e atualizar a Tabela de Acompanhamento
da Implementao dos Aspectos. Como o caso de uso Reajustar Valor das Dirias funcional
e foi originalmente alocado para ser desenvolvido nesta iterao, optou-se por implementar a
nova funcionalidade aspectual na iterao atual. Portanto, a Tabela de Acompanhamento
mostrada na Tabela 7.18.
215
O prosseguimento do processo consiste em elaborar um diagrama de interao para a
funcionalidade de reajuste do valor das dirias. Entretanto, como essa funcionalidade ser
implementada com o apoio do novo FT, esse diagrama s poder ser elaborado depois que o
FT estiver acoplado ao sistema. Isso ocorre porque a utilizao desse FT disponibiliza
algumas operaes prontas que devem ser utilizadas na implementao da funcionalidade e,
conseqentemente, na elaborao dos diagramas de projeto. Assim, neste momento o
processo sai de seu fluxo normal para dar lugar ao processo de reso do FT, o qual consiste na
etapa de instanciao e composio.
Tabela 7.18 Tabela de Acompanhamento da Implementao dos Aspectos
No. Iterao Aspecto
2.da elaborao Gerenciar Empresas
2. Construo Estratgias e tipos de Reajuste

Na Figura 7.33 mostrado o modelo de projeto do FT de Reajuste de Valor j com as
classes e aspectos que devem ser criados durante a instanciao, os quais esto destacados em
cinza. Como o objetivo que haja trs estratgias de reajuste disponveis no sistema, ento as
trs variabilidades do framework devem ser utilizadas.
A escolha das variabilidades feita criando-se classes concretas que estendem
determinadas classes abstratas do FT. Por exemplo, a criao das trs classes:
MyAllCategories, MySpecificCategory e MyNonLinearIncrease, determina que as
trs estratgias sejam introduzidas no sistema, j que cada uma dessas classes estende uma
determinada classe abstrata do FT que representa uma estratgia. Se uma determinada
estratgia no fosse necessria no sistema, o processo consistiria apenas em no criar uma
classe concreta que estendesse a classe abstrata correspondente.
Os mtodos que aparecem na classe MyAllCategories so mtodos que
concretizam mtodos-gancho da classe estendida e que tm a funo de retornar valores e
informaes especficas da aplicao-base. Embora as classes MySpecificCategories e
MyNonLinearIncrease estejam sendo exibidas sem mtodos, esses foram suprimidos para
facilitar a visualizao, porm considere-se que todos os mtodos-gancho foram
concretizados. Note-se que durante a etapa de instanciao, o aspecto
ReadjustmentPolicy do FT tambm deve ser estendido e alguns de seus mtodos-gancho
concretizados.
O modelo de projeto mostrado na Figura 7.33 consiste em um tema-base que ser
composto com a aplicao. Durante a composio, deve-se informar uma classe de aplicao

216
que far correspondncia com a interface IValueIncrease e assumir todos as operaes
nela definidas, isto , os trs mtodos increaseValue().

Figura 7.33 Modelo de Projeto do FT de Reajuste de Valor Instanciado
Na Figura 7.34 mostrada a composio entre o FT de Reajuste de Valores e a
Aplicao-Base. O FT est sendo representado apenas pela interface IValueIncrease e a
aplicao apenas pela classe TipoAcomodacao, por questes de legibilidade. O
relacionamento de composio entre os pacotes representa que a classe TipoAcomodacao
corresponde interface IValueIncrease. Dessa forma, os trs mtodos mostrados na
interface IValueIncrease sero introduzidos na classe TipoAcomodacao e podem ser
utilizados normalmente durante o projeto e a implementao do sistema. O modelo de projeto
resultante da composio no est sendo exibido por motivos de economia de espao. Depois
que o FT foi instanciado e acoplado parte base da aplicao, o processo pode retornar ao seu
fluxo normal para continuar a elaborao dos diagramas de interao.

ReadjustmentPolicy
Li nearIncrease
percentageOrFi xVal ue
returnIncreaseStrategy()
NonLi nearIncrease
categori esAndIncreaseStrategi es
cal cul ateNewVal ue_BasedOn_Thi sVal ue()
i ncreaseVal ue()
Speci fi cCategory
pri vi l egedCategori es
cal cul ateSal ary_BasedOn_Thi sVal ue()
i ncreaseVal ue()
myAl l Categori es
getVal uePri mi ti veType()
getTypeNameWi thPackage()
getCl assOfTheVal ueWi thPackage()
getMethodResponsi bl eForSetti ngThePri mi ti veVal ue()
getMethodResponsi bl eForReturni ngthePri mi ti veVal ue()
getMethodResonsi bl eForReturni ngTheVal ueObj ect()
getMethodResponsi bl eForSetti ngTheVal ueObj ect()
getMethodResponsi bl eForReturni ngTheTypeDescri pti on()
MySpeci fi cCategory MyNonLi nearIncrease
Al l Categori es
cal cul ateNewVal ue_BasedOn_Thi sVal ue()
i ncreaseVal ue()
MyReadj ustmentPol i cy
getNameOfCl assExtendi ngSpeci ficCategori es()
getNameOfCl assExtendi ngAl l Categori es()
getNameOfCl assExtendi ngNonLInear()
Fi xVal ue
Percentage
Fi xVal uePl us
Percentage
ReadjustmentPol i cy
<<hook>> getNameOfCl assExtendi ngAl l Categori es()
<<hook>> getNameOfCl assExtendi ngNonLi near()
<<hook>> getNameOfCl assExtendi ngSpecifi cCategori es()
Readj ustmentTypes
ReadjustmentStrategi es
IVal ueIncrease
i ncreaseVal ue(estrategi aReaj uste : Readj ustmentTypes, ti posAcomodacao : Vector)
i ncreaseVal ue(estrategi aReaj uste : Readj ustmentTypes)
i ncreaseVal ue(estrategi aReaj uste : Hashtabl e)
<< Interface>>
217

Figura 7.34 Acoplamento FT de Reajuste de Valor com Aplicao Base
7.6.2.4 Desenvolver Viso da Arquitetura
A atualizao que deve ser realizada aqui em comparao com a Viso da Arquitetura
anterior, consiste apenas na adio do FT de Reajuste de Valores, como mostrado na Figura
7.35.

Figura 7.35 Viso da Arquitetura 2a. Iterao da Construo
7.6.2.S Atualizar Regras de Composio
Com o aparecimento das novas classes de interface srvReajustarValorDiarias,
srvReajustarTodosTipos e srvReajustarTiposSelecionados, a parte de conexo
com o banco de dados do FT de persistncia deve ser atualizada. Assim, na Figura 7.36 so
mostradas as atualizaes realizadas em negrito.
7.6.2.6 - Registrar Pontos de Juno
Depois que as regras de composio foram atualizadas deve-se atualizar o Registro de Pontos
de Juno do Sistema. Assim, com base nas regras de composio mostradas na Figura 7.36,
o novo Registro de Pontos de Juno est sendo mostrado pela Tabela 7.19. Note-se que,
embora um novo FT tenha sido adicionado ao sistema o de Reajuste de Valores sua
influncia esttica, e no precisa ser discriminada nesta tabela.

ValueReadjustment
Aplicacao
IVal ueIncrease
i ncreaseVal ue(estrategi aReaj uste : Readj ustmentTypes, ti posAcomodacao : Vector)
i ncreaseVal ue(estrategi aReaj uste : Readj ustmentTypes)
i ncreaseVal ue(estrategi aReaj uste : Hashtabl e)
<< Interface>>
TipoAcomodacao
ID
descricao
preco
increaseValue()
increaseValue()
increaseValue()
FT Persistencia
Persistent Entities
Empresa
NewInterface
Aplicacao
<<crosscuts>>
FT Reajuste de Valor
<<crosscuts>>

218

Figura 7.36 Atualizao das Regras de Composio da Conexo
Tabela 7.19 Registro de Pontos de Juno 2a. Iterao da Construo
FT/Aspecto
Classe Aspecto
FT de
Persistencia
... ...
Como se optou por utilizar um FT para a implementao do reajuste de valor das dirias, esta
atividade consiste no processo de reso desse FT. Na Figura 7.37 mostrada a implementao
da classe MyAllCategories, que uma das classes da etapa de instanciao do FT, como
pode ser visto na Figura 7.33. As outras duas classes que tambm devem ser criadas durante a
etapa de instanciao no esto sendo exibidas porque so bastante similares.

Figura 7.37 Classe MyAllCategories
Persistence
Aplicacao
srvOcuparReserva.init(), srvCancelarReserva.init(),
srvFaturarReservasNaoOcupadas.init(), srvReajustarValorDiarias.init(),
srvReajustarTodosTipos.init(), srvReajustarTiposSelecionados() ...}
srvOcuparReserva.destroy(), srvCancelarReserva.destroy(),
srvFaturarReservasNaoOcupadas.destroy(..), srvReajustarValorDiarias.destroy(),
srvReajustarTodosTipos.destroy(), srvReajustarTiposSelecionados()...}
public class MyAllCategories extends AllCategories {

public MyAllCategories(ReadjustmentTypes increaseStrategy){
super(increaseStrategy);
}
public MyAllCategories(){
super();
}
public String getTypeNameWithPackage(){
return "application.TipoAcomodacao";
}
public String getMethodResponsibleForReturningTheTypeDescription(){
return "getDescricao";
}
public String getMethodResponsibleForReturningTheValueObject(){
return "";
}
public String getMethodResponsibleForSettingTheValueObject(){
return "";
}
...
}

219
Na Figura 7.38 mostrado o aspecto MyReadjustmentPolicy, que deve ser criado
durante a etapa de instanciao para sobrepor trs mtodos, mas que tambm atualizado na
etapa de composio para fornecer as regras de composio que unem o FT com a parte-base
do sistema. A regra de composio que deve ser fornecida consiste na declarao declare
parents, a qual faz com que a classe de aplicao TipoAcomodacao implemente a interface
IValueIncrease do FT.
Depois que o aspecto foi implementado, deve-se atualizar a Tabela de Aspectos para
registrar sua implementao. Nesse sentido, na Tabela 7.20 mostrada a Tabela de Aspectos
atualizada. Note-se que a funcionalidade de estratgias de reajuste agora est marcada com
um X, indicando que sua implementao foi realizada. Note-se tambm que o caso de uso
Enviar Dados por E-mail no contm mais a palavra adiada na coluna Implementa com
Aspecto?.

Figura 7.38 Aspecto MyReadjustmentPolicy
7.6.4 - Planejar Iteraes
Na Tabela 7.20 mostrado que ainda h quatro casos no-funcionais (Autenticar Usurio,
Controlar Acesso, Gerenciar Usurios e Registrar Operaes) e um funcional (Calcular
Desconto) que ainda no foram implementados. Assim como foi feito na fase de concepo,
os casos de uso devem ser classificados para decidir a ordem de implementao, conforme
est sendo mostrado na Tabela 7.21.
Optou-se por planejar trs iteraes, como mostrado na Tabela 7.22. A primeira
iterao responsvel pelo caso de uso funcional Calcular Desconto e as demais pelos no-
funcionais. A segunda iterao ir tratar de trs casos de uso: Autenticar Usurio, Gerenciar
Usurios e Controlar Acesso. Isso est sendo feito porque Gerenciar Usurios e Controlar
Acesso fazem parte do interesse de Autenticao.

public aspect MyReadjustmentPolicy extends ReadjustmentPolicyIntroduction {

declare parents: TipoAcomodacao implements IValueIncrease;

public String getNameOfClassExtendingAllCategories(){
return "valueIncrease.instantiation.MyAllCategories";
}
public String getNameOfClassExtendingSpecificCategories(){
return "valueIncrease.instantiation.MySpecificCategories";
}
public String getNameOfClassExtendingNonLinear(){
return "valueIncrease.instantiation.MyNonLinearIncrease";
}
}

220
Tabela 7.20 Tabela de Aspectos Atualizada
Casos de Uso Tipo Atomicidade Volatilidade FT Implementa
como Aspecto?
Implementado?
Persistir
Dados
NF - - S Sim
Registrar
Operaes
NF - - S Sim
Enviar Dados
por E-mail
F s N N No
Controlar
Acesso
NF - - S Sim
Autenticar
usurio
NF - - S Sim
Calcular
Desconto
F s s S Sim
Gerenciar
Empresas
F s s N sim
Gerenciar
Usurios
NF s n S sim
Funcionalidades Extra
Nome
Estratgias e
Tipos de
Reajuste
F s s S Sim
Tabela 7.21 Classificao dos Casos de Uso Aspectuais
Casos de Uso Tipo
Calcular Desconto F
Autenticar usurio NF
Controlar Acesso NF
Gerenciar Usurios NF
Registrar Operaes NF
Tabela 7.22 Tabela de Planejamento das Iteraes do Sistema de Reservas

7.7 IASL DL CONS1RUO J. I1LRAO ASPLC1UAL
Esta primeira iterao aspectual da fase de construo concentra-se no desenvolvimento do
caso de uso Calcular Desconto. Na Figura 7.39 mostrada a viso de iterao para esta
iterao.
7.7.J Disciplina Projeto
Durante a atividade Projetar Aspectos, observou-se pela Tabela de Aspectos (Tabela 7.20) a
existncia de um FT que pde ser utilizado para apoiar a implementao do caso de uso
Calcular Desconto. Assim, os modelos de projeto desse FT tambm foram utilizados no
projeto. Como o processo de reso desse FT j foi exemplificado na Seo 3.3, as atividades
Iteraes Aspectuais
1 Iterao Calcular Desconto
2 Iterao

Autenticar Usurio
Gerenciar Usurios
Controlar Acesso
3 Iterao Registrar Operaes
221
Projetar Aspectos, Acoplar Aspectos e Desenvolver Modelo de Projeto Composto no sero
discutidas nesta iterao.

Figura 7.39 Viso de Iterao 3a. Iterao da Construo
Na atividade Desenvolver Viso da Arquitetura, o novo diagrama que agora considera
tambm o FT de Clculo, pode ser visto na Figura 7.40. Na atividade Registrar Pontos de
Juno a Tabela 7.23 foi atualizada, mostrando que o FT de Clculo est projetado para afetar
apenas dois pontos do cdigo-base, como pode ser visto na ltima linha da Tabela. Como
nenhum outro aspecto afeta esse mesmo ponto de juno, nenhuma estratgia de precedncia
precisou ser definida.

Figura 7.40 Viso da Arquitetura do Sistema

Registrar Operaes
<<NF>>
CalcularDesconto
Controlar Acesso
<<NF>>
Fazer Reserva
<<extend>>
<<extend>>
Al terar Reserva
<<extend>>
Listar Reservas por Periodo
<<constrai n>>
<<constrain>>
Reajustar Valor das Diarias
<<constrai n>>
No Comparecer
<<extend>>
<<constrain>>
Ocupar Reserva
<<extend>>
<<constrain>>
Gerenciar Usuarios
<<constrai n>>
Persistir Dados
<<NF>>
<<constrai n>> <<constrain>>
Autenticar Usurio
<<NF>>
<<constrain>>
<<constrai n>>
<<constrain>>
<<constrai n>>
<<constrain>>
<<constrai n>>
<<constrain>>
Criptografar Dados
<<NF>>
<<constrain>>
x
FT Persist enci a
<<aspectual component >>
Persistent Entities
Empresa
NewInt erface
Aplicacao
<<crosscuts>>
<<aspect ual component>>
<<crosscuts>>
FT Calculo Baseado em Tabela

222
Tabela 7.23 Registro de Pontos de Juno
FT/Aspecto

Mtodo/atributo/construct
or/adendo Classe Aspecto
FT de Persistencia ... ...
FT de Clculo
Baseado em Tabela
calcularValorTotal()
setValorTotal()
Fatura
Fatura

7.7.2 - Disciplina Implementao
7.7.2.J Implementar Aspectos
Na Figura 7.41 mostrado o aspecto MeuAspecto, que criado para fornecer as regras de
composio entre o FT de Clculo e o sistema de reservas. Esse aspecto estende um aspecto
abstrato do FT chamado TBWithReturn e concretiza o conjunto de juno obtainValue
com a execuo do mtodo calcularValorTotal() da classe Fatura. Alm disso, dois
mtodos gancho tambm so concretizados, o primeiro, chamado
getHooksHandlerInstance() retorna uma instncia da classe criada anteriormente,
enquanto que o segundo, getTableName(), retorna o nome da tabela criada no banco de
dados.

Figura 7.41 Aspecto MeuAspecto
No caso do sistema de reservas optou-se por remover as alternativas de composio
que no esto sendo utilizadas. Isso foi feito porque os benefcios de manuteno que podem
ser obtidos com um cdigo mais claro compensa o trabalho futuro de adio de novas
alternativas, que pode ou no ocorrer. Sendo assim, o modelo de projeto composto final est
sendo mostrado na Figura 7.42. Note-se que as alternativas de composio que foram
removidas foram OneStringArgument e WithParameters.

public aspect MeuAspecto extends TBWithReturn {

public pointcut obtainValue():
execution (public float Fatura.calcularValorTotal(..));

public WithReturnI getHooksHandlerInstance(){
return new MeuDesconto();
}

public String getTableName(){
return "Desconto";
}
}
223

Figura 7.42 Modelo de Projeto Composto do Sistema de Reservas 1a. Iterao Aspectual
7.8 IASL DL CONS1RUO 2. I1LRAO ASPLC1UAL
Esta segunda iterao aspectual da fase de construo concentra-se no desenvolvimento dos
casos de uso Autenticar Usurio, Gerenciar Usurio e Controlar Acesso. Na Figura 7.43
mostrada a viso de iterao do sistema de reservas para esta segunda iterao. Os FTs de
Autenticao e de Controle de Acesso podem ser utilizados para apoiar o desenvolvimento
desses casos de uso. Porm, como o FT de Autenticao j foi exemplificado na Seo 4.4
esta seo concentra-se no processo de reso do FT de Controle de Acesso.
7.8.J - Disciplina Projeto
7.8.J.J Projetar Aspectos
Como h um FT que pode ser usado para a implementao do interesse de controle de acesso,
seus modelos de projeto tambm sero reusados. Na Figura 7.44 mostrado o modelo de
projeto do FT de Controle de Acesso. As classes com esteretipo <<jsp>> so interfaces que
permitem realizar o gerenciamento dos usurios, de seus papis e das operaes que os papis
podem executar no sistema.

Aplicacao
TBTarget
TBThis
TBArgs
WithoutDeductible
applyCalculation()
WithDeductible
deductible
applyCalculation()
IndirectAcces
performCalculation(Object)
<<hook>> getSetMethodInChargeOfSettingValue()
<<hook>> getGetMethodInChargeOfGettingValue()
WithReturn
performCalculation(float)
DirectAccess
getHooksHandlerInstance()
WithoutParamet ers
<<hook>> getJoinPointObject(JoinPoint) : Object
Desconto
isIncrement()
MeuDescontoComRetorno
getValueType()
getVariabilityInstance()
Calculation
ID
ini ti alValue
fi nalValue
percentage
applyCalculation()
calculat eNewValueBasedOnThis()
<<hook>> i sIncrement()
TBHooksHandler
<<hook>> getVariabi lityInstance() : Calcul ation
<<hook>> getValueType() : String
perf ormCalculation()
Fatura
do_calcularValorTotal()
srvUpdateOnl yValues
srvVisualizeTable
srvCreateNewCalculationRange
MeuDescontoTarget
getVariabil it yInstance()
getGet Met hodInChargeOfGett ingValue()
getSet Met hodInChargeOfSet ti ngValue()
getVal ueType()
Aspectos:
TBWithReturn
TBThisTargetArgs
TBOneArgument
TBWithParameters

224

Figura 7.43 Viso de Iterao para o Sistema de Reservas 2. Iterao Aspectual da Construo
Como o FT de Controle de Acesso inclui o gerenciamento de usurios, o caso de uso
Gerenciar Usurio tambm ser implementado nesta iterao.
7.8.J.2 - Acoplar Aspectos
Como um FT est sendo utilizado, o primeiro passo instanci-lo, o que consiste em projetar
uma classe concreta que estende a classe SecurityOperations do FT sobrepondo os
mtodos necessrios. A sobreposio desses mtodos define um mapeamento entre os
mtodos da aplicao que devem ter o acesso controlado e nomes fictcios, que so usados nas
interfaces de gerenciamento de papis e operaes. Na Figura 7.45 mostrado o modelo de
projeto do FT agora com a classe MySecurityOperations, que deve ser criada para
instanciar o framework.
Como o FT de Controle de Acesso depende do FT de Autenticao, antes de projetar a
composio do controle de acesso com a aplicao, deve-se realizar a composio entre esses
dois FTs, como mostrado na Figura 7.46. Essa composio do tipo intercalao, em que as
classes que possuem o mesmo nome em ambos os pacotes so transformadas em apenas uma
CalcularDesconto
Controlar Acesso
<<NF>>
Enviar Dados E-mail
Registrar Operaes
<<NF>>
Fazer Reserva
Alterar Reserva
Listar Reservas por Periodo
Reajust ar Valor das Diarias
No Comparecer
Ocupar Reserva
Gerenciar Usuarios
Persi stir Dados
<<NF>>
Autent icar Usurio
<<NF>>
Criptografar Dados
<<NF>>
<<extend>>
<<extend>>
<<extend>>
<<constrain>>
<<constrain>>
<<constrain>>
<<extend>>
<<constrain>>
<<extend>>
<<constrai n>>
<<constrain>>
<<constrai n>> <<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrain>>
<<constrai n>>
x x x
225
e as que possuem nomes diferentes sero adicionadas no pacote resultante. Neste caso, apenas
a classe Role ser mesclada em apenas uma.

Figura 7.44 Modelo de Projeto do FT de Controle de Acesso 3a. Iterao Aspectual

Na Figura 7.47 mostrado o projeto da composio do FT transversal resultante com
a aplicao. Note-se que vrios mtodos so informados no relacionamento de ligao entre
os pacotes. Esses mtodos correspondem aos pontos do sistema em que o acesso deve ser
controlado.
Na Figura 7.48 mostrado o modelo de projeto composto. Apenas algumas classes de
aplicao esto sendo exibidas para facilitar a legibilidade do modelo.

ApplicationClass : Security AccessControlException
secureOperat ion()
t est : = analyseRights( )
[ test = true] do_analyseRights()
[test = false] new()
AccessControl ApplicationClass.secureOperation()
Operation
ID
name
Role
ID
descript ion
. ..
1..n
1..n
1..n
1..n
Subject
1
1..n
1
1..n
OperationDetails
name
returnType
packageName
ownerClass
parameterTypes
JPoint
kind
asString()
getCompleteDefinit ion()
SecurityOperations
setOperations()
<<hook>> setPersistentEntitiesForPeristentOperations()
<<hook>> setQueryOperations()
<<hook>> setBusinessOperations()
<<hook>> defineMappingInsertionOperationsAndEntities()
<<hook>> defineMappingRemovalOperationAndEntities()
<<hook>> defineMappingUpdatingOperationsAndEntities()
<<hook>> defineMappingReportOperationsAndReportNames()
<<hook>> defineMappinBusinessOperationAndBusinessOperationName()
IMainSecurity
setPeristent Operat ions()
addOperat ion()
setAdminConfigurations()
addApplicatonPersistentEntities()
InsertionOfRoles
<<jsp>>
InsertionOfSubjects
<<jsp>>
MaintenanceOfRoles
<<jsp>>
MaintenanceOfSubjects
<<jsp>>
Security
allOperations
operations
AppicationPersistentEntities
RemovalOperations
InsertionOperations
UpdatingOperations
addOperation()
addApplicationPersistentEntities()
setPersistentOperations()
setAllOperations()
identifyTargetOperation()
analyseRights()
AccessControlHooksHandler
getObject()
identifyTarget Operation()
analyseRights()
ApplicationClass
secureOperation()
do_secureOperation()
WithParametersAccessControl
getObj ect()
getNumberOfParameters()

226

Figura 7.45 Modelo de Projeto Instanciado

Figura 7.46 Acoplamento com o FT de Autenticao
7.8.J.3 - Desenvolver Viso da Arquitetura
Na Figura 7.49 mostrada a Viso da Arquitetura para esta terceira iterao aspectual.
7.8.J.4 Registrar Pontos de Juno
A Tabela de Registro de Pontos de Juno deve ser atualizada com os pontos de juno do
sistema que foram afetados pelo FT de Controle de Acesso, como pode ser visto na ltima
linha da Tabela 7.24. Pode-se notar que alguns pontos de juno tambm so afetados pelo FT
de Autenticao, entretanto, como o FT de controle de acesso foi projetado para trabalhar em
Autenticacao
Role
ID
description
getDescription()
getID()
Subject
ID
name
userName
password
1
1..n
AccessControl
ThemeName[Aplicacao]
match[name]
Operation
ID
name
Role
catchOperati on()
showAvailabl eOperati ons()
1..n
1..n
1..n
1..n
Subject
1
1..n 1..n
1
Operation
ID
name
Role
ID
descript ion
. ..
1..n
1..n
1..n
1..n
Subject
1
1..n
1
1..n
OperationDetails
name
returnType
packageName
ownerClass
parameterTypes
JPoint
kind
asString()
getCompleteDefinit ion()
SecurityOperations
setOperations()
IMainSecurity
setPeristent Operat ions()
addOperat ion()
addApplicatonPersistentEntities()
InsertionOfRoles
<<jsp>>
InsertionOfSubjects
<<jsp>>
MaintenanceOfRoles
<<jsp>>
MaintenanceOfSubjects
<<jsp>>
Security
allOperations
operations
RemovalOperations
InsertionOperations
UpdatingOperations
addOperation()
setAllOperations()
analyseRights()
AccessControlHooksHandler
getObject()
identifyTarget Operation()
analyseRights()
ApplicationClass
secureOperation()
do_secureOperation()
WithParametersAccessControl
getObj ect()
getNumberOfParameters()
MySecurityOperations
Aplicacao
227
conjunto com o de autenticao, ele j possui implementado internamente um mecanismo de
precedncia que d prioridade de atuao ao FT de Autenticao.

Figura 7.47 Acoplamento com a Aplicao
A estratgia de desenvolvimento apresentada neste captulo considera a utilizao do
FT de persistncia desde a primeira iterao da elaborao, porm os demais FTs so
acoplados ao sistema depois que a maior parte da funcionalidade principal est pronta. Essa
estratgia permite que a funcionalidade principal da aplicao seja desenvolvida mais
rapidamente e de forma mais cuidadosa, j que no h a preocupao com o projeto e a
implementao de interesses transversais durante o processo. Um ponto negativo da estratgia
adotada que, dependendo do interesse transversal postergado para o final, modificaes
podem ser necessrias na parte base.
Uma outra estratgia de desenvolvimento que poderia ser empregada o acoplamento
dos FTs durante o processo, justamente no momento em que so identificados. Quando essa
estratgia usada o acoplamento dos FTs facilitado, pois os pontos de juno podem ser
projetados com vistas ao acoplamento que ser feito. Alguns trabalhos recentes mostram que
o desenvolvimento de um cdigo-base consciente da existncia de aspectos pode trazer
benefcios de modularidade e manuteno para o sistema (Griswold et al., 2006).

AccessControl
<ApplicationClass.secureOperation()>
AccessControl
Operation
ID
name
Role
catchOperati on()
showAvailabl eOperati ons()
1..n
1..n
1..n
1..n
Subject
1
1..n 1..n
1
ThemeName(Aplicacao)
bind [<srvCadastros.doGet(..),
srvCadastroEmpresas.doGet(..),
srvCadastroHoteis.doGet(..),
srvGerenciamentoTipoAcomodacoes.doGet(..),
srvGerenciamentoAcomodacoes.doGet(..),
srvFaturarReservasNaoOcupadas.doGet(..),
srvOcuparReserva.doGet(..),
srvOcuparReserva2.doGet(..),
srvReajustarValorDiarias.doGet(..),
srvConsultarNumeroReservas.doGet(..),
srvListarReservasPeriodo.doGet(..)>]


228

Figura 7.48 Modelo de Projeto Composto

Figura 7.49 Viso da Arquitetura

doGet()
: srvCadastros : Security AccessControlException
test : = analyseRights( )
[test = true] do_doGet( )
[test = false] new()
Aplicacao
Securi tyOperat ions
setOperations()
IMainSecurity
setPerist entOperations()
addOperation()
setAdminConfi gurati ons()
addApplicat onPersistent Enti ties()
InsertionOfRoles
<<jsp>>
InsertionOfSubjects
<<jsp>>
MaintenanceOfRoles
<<jsp>>
Mai ntenanceOfSubjects
<<jsp>>
Operation
ID
name
Role
ID
description
getDescription()
getID()
showAvailableOperations()
catchOperation()
1. .n
1. .n
1. .n
1. .n
Subject
1
1..n
1
1..n
OperationDetails
name
returnType
packageName
ownerClass
parameterTypes
JPoint
kind
asString()
getCompleteDefinition()
srvCadastroEmpresas
doGet()
do_doGet()
srvCadastros
doGet()
do_doGet()
srvGerenciamentoTipoAcomodacoes
doGet()
do_doGet()
srvCadastroHoteis
doGet()
do_doGet()
Security
allOperations
operations
RemovalOperations
InsertionOperations
UpdatingOperations
addOperation()
setAllOperations()
analyseRights()
MySecurityOperations
FT Persist enci a
Persistent Entities
Empresa
NewInt erface
Aplicacao
<<crosscuts>>
<<aspect ual component>>
<<crosscuts>>
FT Calculo Baseado em Tabela
FT Autenti cacao
FT Controle de Acesso
229
Tabela 7.24 Registro de Pontos de Juno
FT/Aspecto
Classe Aspecto
FT de
Persistencia
... ...
FT de
Clculo
Baseado em
Tabela
setValorTotal()
Fatura
Fatura

FT de
Autenticao
... ...
FT de
Controle de
Acesso
doGet()
doGet()
doGet()
doGet()
doGet()
doGet()
doGet()
doGet()
doGet()
doGet()
srvCadastroEmpresas
srvCadastroHoteis
srvGerenciamentoTipoAcomodacoes
srvGerenciamentoAcomodacoes
srvFaturarReservasNaoOcupadas
srvOcuparReserva
srvOcuparReserva2
srvReajustarValorDiarias
srvConsultarNumeroReservas
srvListarReservasPeriodo

Embora os FTs utilizados foram acoplados no final do desenvolvimento, nada garante
que essa estratgia possvel com qualquer sistema. Novas aplicaes precisam ser
desenvolvidas seguindo o ProFT/PU para averiguar essa questo. Dois novos FTs funcionais
foram desenvolvidos e includos no repositrio e deu-se incio uma nova famlia de FTs
denominada Regras de Negcio, como j havia sido apresentado na Tabela 4.1.


230

Captulo 8

Covc t v.ao
O trabalho realizado pode ser dividido em duas fases. Na primeira foram definidos,
especificados e desenvolvidos os FTs de Persistncia e de Segurana. A experincia com o
desenvolvimento desses FTs permitiu elaborar uma arquitetura comum para esse tipo de
software, a qual apresentada na Seo 3.3. Ainda nessa primeira fase, o levantamento
bibliogrfico permitiu a identificao de falta de padronizao em relao aos termos
utilizados para designar frameworks desenvolvidos no contexto da POA. Assim, foram
propostas as definies de Framework Orientado a Aspectos, Framework Transversal e
Framework de Aplicaes Orientado a Aspectos.
Na segunda fase, o objetivo foi avaliar o impacto da disponibilidade de FTs sobre o
processo de desenvolvimento de software. Para isso, um sistema de reserva de uma rede
hotis foi desenvolvido com o cuidado de observar pontos de deciso influenciados pela
presena de interesses transversais e dos FTs disponveis. Durante o desenvolvimento desse
sistema, dois novos FTs funcionais foram desenvolvidos, os FT de Clculo Baseado em
Tabela e o FT de Reajuste, dando origem a uma nova famlia de FTs. Como base nessa
experincia, um processo de desenvolvimento de software baseado no PU, incremental e
iterativo, e que leva em considerao a possibilidade de implementar os interesses transversais
como aspectos, possivelmente usando FTs, foi desenvolvido.
Como parte da pesquisa, dois estudos de caso informais e um estudo de caso formal
foram conduzidos com o objetivo de testar e avaliar as vantagens e desvantagens de se usar
FTs em relao a outras alternativas, como a implementao orientada a objetos. Esses
Captulo 8 Concluso

232
estudos tambm foram teis para testar os frameworks e aprimorar sua arquitetura e
funcionalidade.
8.2 CON1RIBUILS DLS1A 1LSL
A principal contribuio deste trabalho tornar o reso de interesses transversais mais efetivo
por meio do fornecimento de um conjunto de tcnicas, padres, diretrizes, implementaes e
teorias. As contribuies mais especficas so as definies e classificaes propostas para
designar frameworks desenvolvidos no contexto da POA, a arquitetura de referncia e o
padro Capturador de Dados para projeto e implementao de FTs, as famlias de FTs
desenvolvidas e o processo ProFT/PU.
A padronizao de termos relativos a frameworks orientados a aspectos (Camargo e
Masiero, 2005a) evita que o mesmo tipo de implementao seja referenciado de formas
diferentes e que tipos diferentes de implementao sejam referenciados pelo mesmo termo.
Assim, pretende-se que o termo Framework Transvesal seja utilizado por outros
pesquisadores para designar frameworks que tratem de um nico interesse transversal.
A arquitetura de referncia para FTs, juntamente com o padro Capturador de Dados,
constituem uma forma de projetar e implementar um FT. A parte comportamental do FT pode
ser projetada com padres de projeto convencionais (Gamma et al., 1005) enquanto que a
parte de composio com o padro Capturador de Dados, evidenciando uma clara separao
em sua arquitetura. Alm de facilitar o raciocnio modular (Kiczales e Mezini, 2005), facilita
o processo de reso, tornando mais clara a diviso dos passos que so realizados nas etapas de
instanciao e composio. Alm disso, a utilizao de uma arquitetura padro facilita a
integrao de vrios FTs em um repositrio nico, algo que tm sido buscado por pesquisas
mais recentes (Zhang et al., 2004; Mortensen e Ghosh, 2006a; Mortensen e Ghosh, 2006b;
Soares, 2004).
Outra contribuio so os produtos gerados pela pesquisa realizada. Trs interesses
transversais foram implementados de forma genrica: persistncia, segurana e regras de
negcio. Optou-se por implementar esses interesses como famlias de FTs, em que algumas
caractersticas tambm foram implementadas como FTs, facilitando o acoplamento e
permitindo que essas caractersticas tambm possam ser reusadas fora de sua linha de
produtos original (Weiss e Lai, 1999; Gomaa, 2004). Os interesses transversais foram
implementados como famlias para, em parte, ter as variabilidades implementadas como
aspectos (FTs) o que facilita o acoplamento e o reso parcial e para evitar o problema de
overfeaturing, que causado pela utilizao exclusiva de frameworks (Codenie et al., 1997
Captulo 8 Concluso
233
apud (Batory et al., 2000))
24
. Pretende- disponibilizar os FTs desenvolvidos em um
repositrio de projetos de software, como por exemplo o SourgeForge (2006).
Outra contribuio desta tese o processo ProFT/PU. Esse processo iterativo e
incremental e fortemente baseado na identificao e acompanhamento de interesses
transversais ao longo do processo. Ele formado pela unio de conceitos, tcnicas de
modelagem e critrios de outros trabalhos encontrados na literatura (Clarke e Baniassad,
2005; Jacobson e Ng, 2004; Baniassad et al., 2006; Krechetov et al., 2006; Arajo e Moreira,
2003; Arajo et al., 2002). Ele fornece diretrizes e sugestes sobre como reutilizar o projeto e
o cdigo de aspectos reusveis (disponveis em um repositrio, por exemplo) durante o
desenvolvimento de um software. Embora ProFT/PU tenha sido criado e exemplificado com a
famlia de FTs desenvolvida no contexto desta tese, no especfico dessa tecnologia. Os
critrios de identificao de interesses e os pontos de deciso so aplicveis ao reso de
aspectos disponveis na forma de FTs, a uma biblioteca de aspectos (Zhang et al., 2004;
Mortensen e Ghosh, 2006a; Mortensen e Ghosh, 2006b) e at mesmo implementao
baseada em aspectos, sem reso.
8.3 LIMI1ALS DO 1RABALHO LIL1UADO
8.3.J Limitaes relacionadas aos I1s
Uma limitao do trabalho realizado quanto a carncia de experimentos formais que
compare o reso de interesses transversais implementados com FT com o reso de interesses
transversais implementados com orientao a objetos. Embora um experimento tenha sido
feito nesse sentido, apenas o tempo de composio foi comparado. Um estudo mais completo
deveria avaliar tambm a manuteno do sistema aps o reso dos FTs.
A utilizao dos gabaritos da abordagem Tema durante o projeto no representam
adequadamente detalhes da linguagem AspectJ. Assim, necessrio manter um modelo de
projeto que represente o comportamento do FT (gabarito) e outro modelo de projeto para
representar detalhes especficos da linguagem.
Todos os sistemas utilizados como estudos de caso pertencem ao mesmo domnio de
Sistemas de Informao. Assim, o desenvolvimento dos FTs foi feito de forma muito restrita.
Pode ser que seu reso em outros contextos exija um nmero grande de adaptaes, o que
pode inviabilizar a adoo dos FTs. Portanto, experimentos em outros domnios poderiam
contribuir para a evoluo dos FTs

24
Captulo 8 Concluso

234
A utilizao nica da linguagem AspectJ para o desenvolvimento dos FTs, e
conseqentemente, de todas as generalizaes efetuadas, como, por exemplo, as definies, a
arquitetura, o padro Capturador de Dados, podem ter sido influenciados pelas
particularidades dessa linguagem. Um estudo que envolva construes e novos mecanismos
disponveis em outras linguagens orientadas a aspectos poderia levar a melhores solues na
arquitetura proposta.
8.3.2 Limitaes relacionadas ao Processo ProI1/PU
A principal limitao do trabalho com relao ao processo apresentado no Capitulo 6 a
carncia de ferramentas de apoio. A construo de todos os artefatos manualmente,
principalmente as tabelas, uma tarefa que consome muito tempo e que tende a gerar erros.
Apoio automatizado tambm poderia ser fornecido para a identificao e recuperao de FTs
do repositrio. Outra limitao do processo o fato de no tratar da fase de Transio do PU.
8.3 SUGLS1LS DL 1RABALHOS IU1UROS
H vrios trabalhos futuros que podem ser conduzidos como continuao da pesquisa iniciada
por esta tese. Um desses trabalhos a construo de ferramentas de apoio ao ProFT/PU. Essas
ferramentas poderiam auxiliar no acompanhamento do processo e na construo dos modelos
de projeto.
Um outro trabalho seria implementar algum mecanismo de suporte evoluo do FT
de Persistncia. Isso se mostra necessrio quando operaes muito especficas de consultas
precisam ser criadas. Nesses casos, a dificuldade em se criar uma nova operao no
Framework ou mesmo na classe de aplicao que instancia o framework, pode inviabilizar seu
uso.
Tambm pode-se investigar uma linguagem de modelagem mais adequada para o
desenvolvimento de sistemas em AspectJ do que os gabaritos da abordagem Tema. Embora os
gabaritos sejam teis para descrever o comportamento do interesse transversal, negligencia a
implementao. Nessa mesma linha, tambm pode-se investigar uma notao especfica para
FTs. Embora Rausch et al. (2003) tenham feito um trabalho neste sentido, ainda h muito para
pesquisar. Uma alternativa seria estender o perfil UML-F (Fontoura et al., 2002) para
incorporar esteretipos e etiquetas valoradas que representam particularidades especficas de
frameworks orientados a aspectos.

Captulo 8 Concluso
235
O FT de Garantia de Polticas implementa apenas dois testes com respeito ao FT de
Persistncia. Esse FT poderia ser estendido para verificar todas as polticas exigidas durante o
processo de reso do FT de Persistncia. O mesmo poderia ser feito para o FT de Segurana.
Em relao ao processo ProFT/PU, mecanismos mais elaborados para o registro dos
pontos de juno e identificao de conflitos entre aspectos devem ser pesquisados. Outro
ponto interessante seria fornecer, juntamente com a documentao dos FTs, no apenas seu
projeto, mas tambm seus modelos de anlise. Assim, durante um processo de
desenvolvimento, alm dos modelos de projeto, seus casos de uso tambm poderiam ser
reusados.
Por fim, um processo de desenvolvimento de Frameworks Transversais poderia ser
elaborado. Embora esta tese apresente uma arquitetura para esse tipo de software, no fornece
diretrizes que possam ser utilizadas para o desenvolvimento de um FT.

Captulo 8 Concluso

236

RLILRLNCIAS BIBLIOGRIICAS
ALDAWUD, O., ELRAD, T., BADER, A. UML Profile for Aspect-Oriented Software
Development. In: Proceedings of Workshop of Aspect Oriented Modeling with UML of
Aspect Oriented Software Development Conference (AOSD), 2003.
ARAJO, J., MOREIRA, A. M. D. An Aspectual Use-case Driven Approach. In: JISBD, pp.
463468, 2003.
ARAJO, J., MOREIRA, A., BRITO, I., RASHID, A. Aspect-Oriented Requirements with
UML. In: proceedings of the Workshop on Aspect-Oriented Modelling with UML (held in
conjunction with the International Conference on Unified Modelling Language UML
2002), 2002
ASPECTWERKZ WEBSITE. Simple, Dynamic, Lightweight and Powerful AOP for Java.
http://aspectwerkz.codehaus.org/
BATORY, D., CARDONE, R., SMARAGDAKIS, Y. Object Oriented Frameworks and
Product Lines. In 1
st
Software Product Lines Conference (SPLC1), 2000.
BANIASSAD, E., CLEMENTS, P.C., MOREIRA, A., ARAJO, J., RASHID, A.,
TEKINERDOGAN, B. Discovering Early Aspects. IEEE Software, pp. 61-70, 2006.
BLAIR, G.S., BLAIR, L., RASHID, A., MOREIRA, A., ARAJO, J., CHITCHYAN, R.
Engineering Aspect-Oriented Systems. In: Chapter 17 of Aspect-Oriented Software
Development, pp. 379-406, Addison-Wesley, 2005.
BERG, K. VAN DEN., CONEJERO, J.M., HERNNDEZ, J. Identification of Crosscutting
In Software Design. In: Proceedings of the Aspect-Oriented Modelling Workshop
(AOM06) in conjunction with Aspect-Oriented Software Development (AOSD06), Bonn,
Alemanha, 2006.
CAMARGO, V.V., MASIERO, P.C. Frameworks Orientados a Aspectos. In: Anais do 19
Simpsio Brasileiro de Engenharia de Software (SBES2005), Uberlndia-MG, Brasil, pp.
200-215, outubro, 2005a.
CAMARGO, V.V., MASIERO, Documentao de Frameworks Transversais com a
Abordagem Tema/UML e o Perfil UML-F. In: Anais do 2 Workshop de
Desenvolvimento de Software Orientado a Aspectos (WASP05) realizado em conjunto
com o Simpsio Brasileiro de Engenharia de Software (SBES'2005), pp. 10-18,
Uberlndia, MG, Brasil, outubro, 2005b. (Artigo premiado e convidado para publicao
na revista RITA).
Referncias Bibliogrficas

238
CAMARGO, V.V., MASIERO, P.C. Uma Abordagem de Evoluo de Sistemas Orientados a
Objetos Apoiada por Frameworks Transversais. In: Anais do Workshop de Manuteno de
Software Moderna (WMSWM05), pp. 18-33, Manaus, Brasil, 2005c.
CAMARGO, V.V., NNA, E., MALDONADO, J.C. Um Estudo Comparativo do Tempo de
Composio de um Framework Orientado a Aspectos de Persistncia e de um Framework
Orientado a Objetos de Persistncia. In: Anais do 20 Simpsio Brasileiro de Engenharia
de Software (SBES), Florianpolis, Brasil, outubro, 2006 (aceito para publicao).
CAMARGO, V.V., RAMOS, R.A., MASIERO, P.C. Implementao de Variabilidades em
Frameworks Orientados a Aspectos desenvolvidos em AspectJ. In: Relatrio do 1
Workshop de Desenvolvimento de Software Orientado a Aspectos (WASP04) realizado
em conjunto com o SBES'2004, Braslia, DF, Brasil, outubro, 2004.
CAMARGO, V.V., RAMOS, R.A., PENTEADO, R.A.D., MASIERO, P.C. Projeto Orientado
a Aspectos do Padro Camada de Persistncia. In: Anais do 17 Simpsio Brasileiro de
Engenharia de Software (SBES), Manaus-Amazonas, Brasil, pp. 114-129, outubro, 2003.
CAYENNE. http://www.objectstyle.org/cayenne/ (ltimo acesso: 04 de abril de 2006)
CHAPIN, N., HALE, J.E., KHAN, K.M., RRAMIL, J.F., TAN, W. Types of Software
Evolution and Maintenance. Journal of Software Maintenance and Evolution: Research
and Practice. Vol. 13, pp 3-30, 2001.
CHAVEZ, C. V. G., GARCIA, A., KULESZA, U.,SANTANNA C., LUCENA, C. Taming
Heterogenerous Aspects with Crosscutting Interfaces. In: Proceedings of Simpsio
Brasileiro de Engenharia de Software (SBES05), pp 216-231, Uberlndia, MG, Brasil,
2005.
CHAVEZ, C.V.G. A Model-Driven Approach for Aspect-Oriented Design. Tese de
Doutorado. Departamento de Computao da PUC-Rio, 2004.
CHEESMAN, J.; DANIELS, J. Uml components: A Simple Process for Specifying
Component-Based Software. Addison-Wesley, 2000.
CHEN, K., HUANG, C. On Designing of Access Control Aspects for Web Applications. In:
Proceedings of the Workshop on Software Engineering Properties of Languages and
Aspect Technologies. Workshop of the 4
th
Aspect-Oriented Software Development
Conference (AOSD05), Maro 14-18, Chicago, USA, 2005.
CIBRN, M., D'HONDT, M., JONCKERS, V. Aspect-Oriented Programming for
Connecting Business Rules. In: Proc. of the 6
th
International Conference on Business
Information Systems (BIS'03). Colorado Springs, USA, June, 2003.
239
CLARKE, S., BANIASSAD, E. Aspect-Oriented Analysis and Design: The Theme Approach.
Addison-Wesley, 2005.
COLYER, A., RASHID, A., BLAIR, G. On The Separation of Concerns in Program
Families. Technical Report, Computing Department, Lancaster University, 2004.
CONSTANTINIDES C. A.; ELRAD T. Composing Concerns with a Framework Approach.
In: International Workshop on Distributed Dynamic Multiservice Architectures in
conjunction with the 21st International Conference on Distributed Computing Systems
(ICDCS). Phoenix, Arizona, USA, Abril, 2001
CONSTANTINIDES C. A.; SKOTINIOTIS T. Reasoning about a Classification of
Crosscutting Concerns in Object-Oriented Systems. In: 2th workshop on aspect oriented
software development of SIG (Software Interesting Group), German Informatics Society.
Bonn, Alemanha, February, 2002.
CONSTANTINIDES C. A.; SKOTINIOTIS T.; Elrad T. Providing Dynamic Adaptability in
an Aspect-Oriented Framework. In: Workshop on Advanced Separation of Concerns
ECOOP 2001. Budapest, Junho 17-18, 2001.
COUTO, C.F.M., VALENTE, M.T.O., BIGONHA, R.S. Um Arcabouo Orientado por
Aspectos para Implementao Automatizada de Persistncia. In: Anais do 2. Workshop
Brasileiro de Desenvolvimento de Software Orientado a Aspectos (WASP05), evento
satlite do XIX SBES, Uberlndia, MG, Brasil, outubro, 2005.
DIJKSTRA, E. W. A Discipline of Programming. Prentice-Hall, 1976.
EICHBERG, M., MEZINI, M., SCHFER, T., Beringer, C., Hamel, K. M. Enforcing
System-Wide Properties. In: Proceedings of Australian Software Engineering Conference
(ASWEC04), pages 158167, Melbourne, Australia. IEEE Computer Society Press, 2004.
ELRAD, T., FILMAN R., BADER A. Aspect-Oriented Programming. Communications of the
ACM, vol 44, pp 29-32, 2001.
FAYAD, M. E., SCHIMIDT, D. C., JOHNSON, R. Building Application Frameworks:
Object-oriented Foundations of Framework Design. John Wiley & Sons, 1999.
FAYAD, M. E., SCHMIDT, D. C. Object-oriented Application Frameworks.
Communications of the ACM, v. 40, n. 10, 1997.
FEATUREC++. URL: wwwiti.cs.uni-magdeburg.de/iti_db/fcc. ltimo acesso em 5 de julho
de 2006.
FONTOURA, M., PREE, W., RUMPE, B. The UML Profile for Framework Architectures.
Addison Wesley, 2002.

240
GAMMA, E., HELM, R., JOHNSN, R., VLISSIDE, J. Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wesley, 1995.
GARCIA, A., SANTANA, C., FIGUEIREDO, E., KULESZA, U., LUCENA C., von STAA,
A. Modularizing Design Patterns With Aspects: A Quantitative Study. In: Proceedings of
the Aspect Oriented Software Development Conference (AOSD05), pp. 3-14, Chicago,
USA, 2005.
GOMMA, Hassan. Designing Software Product Lines With UML From Use Case to
Pattern-Based Software Architectures. Addison Wesley, 1a. Edio, 2004.
GRADECKI, J.D. and LESIECKI, N. Mastering AspectJ Aspect Oriented Programming in
Java. Wiley Publishing, 2003.
GRISWOLD, W.G., SHONLE, M., SULLIVAN, K., SONG, Y., CAI, Y., RAJAN, H.
Modular Software Design with Crosscutting Interfaces, IEEE Software, pp 51-60, 2006.
GRUNDY, J. Aspect-Oriented Requirements Engineering for Component-Based Software
Systems. In: 4
th
Symposium on Requirements Engineering, Limerick, Ireland, IEEE, pp.
84-91, 1999.
GRUNDY, J. Multi-Perspective Specification, Design and Implementation of Software
Components Using Aspects. In: Journal of Software Engineering and Knowledge
Engineering, 20, 6, pp. 713-724, 2000.
HANENBERG, S. Multi-Design Application Frameworks. In: Proc. of the Generative and
Component-Based Software Engineering Young Researchers Workshop, Erfurt, October
10, 2000.
HANENBERG, S., HIRSCHFELD, A., UNLAND, R., KAWAMURA, K. Applying Aspect-
Oriented Composition to Framework Development A Case Study. In: Proc. of the 1
st

International Workshop on Foundations of Unanticipated Software Evolution, Barcelona,
Spain, march 28, 2004.
HANENBERG, S., SCHMIDMEIER, A. Idioms for Building Software Frameworks. In
AspectJ. In 2nd AOSD Workshop on Aspects, Components, and Patterns for
Infrastructure Software (ACP4IS), Boston, MA, March 17, 2003a.
HANENBERG, S., SCHMIDMEIER. A. AspectJ Idioms for Aspect-Oriented Software
Construction. In Proceedings of 8th European Conference on Pattern Languages of
Programs (EuroPLoP), Irsee, Germany, 25th29th June, 2003b.
HANNEMANN, J., KICZALES, G. Design Pattern Implementation in Java and AspectJ.
Proceedings of the 17th Annual ACM conference on Object-Oriented Programming,
Systems, Languages, and Applications (OOPSLA), pages 161-173, November 2002.
241
HIBERNATE. www.hibernate.org (ltimo acesso em 4 de abril de 2006).
HIRSCHFELD, R. Aspect-Oriented Programming with AspectS. In: Proceedings of
Net.ObjectDays (NODe), Erfurt Germany, 2002.
HUANG, M., WANG, C., ZHANG, L. Towards a Reusable and Generic Aspect Library. In:
Proceedings of AOSDSEC04 (AOSD Technology for Application-Level Security).
Workshop of the Aspect Oriented Software Development Conference, Lancaster, UK,
March, 23, 2004.
JACOBSON, I., BOOCH, G., RUMBAUGH, J. The Unified Software Development Process.
Reading, MA. Addison-Wesley, 1999.
JACOBSON, I., NG, P. Aspect-Oriented Software Development With Use Cases. Addison-
Wesley, 2004.
JAML. (2004) http://www.ics.uci.edu/~trungcn/jaml. ltimo acesso em 9/5/2006.
JBoss (2006). http://labs.jboss.com/portal/jbossaop/index.html. ltimo acesso em 14/06/2006.
JOHNSON, R. E., RUSSO, V. Reusing Object-Oriented Designs. Rel. Tcnico. UIUCDCS
91-1696, University of Illinois, 1991.
JOHNSON, R. E. Components, Frameworks, and Patterns. In: Proc. of the ACM Symposium
on Software Reusability, (SST 97), Boston, may, 17-20, 1997.
JOHNSON, R. E., FOOT B. Designing Reusable Classes. Journal of Object-oriented
Programming, 1 (2), 22-35, 1998.
KATARA, M., KATZ, S. Architectural View of Aspects. In: 2
nd
Conference on Aspect-
Oriented Software Development (AOSD), Boston, ACM, pp. 1-10, 2003.
KICZALES, G., LAMPING, J., MENDHEKAR, A., MAEDA, C., LOPES, C., LOINGTIER,
J., IRVING, J. Aspect Oriented Programming. In: Proceedings of 11 ECOOP. pp. 220-
242, 1997.
KICZALES, G., HILSDALE, E., HUGUNIN, J., KERSTEN, M., PALM, J., GRISWOLD, G.
Getting Started With AspectJ, Communications of the ACM, vol 44, No. 10, pp.59-65,
2001.
KICZALES, G., MEZINI, M. Aspect-Oriented Programming and Modular Reasoning. In:
Proceedings of International Conference on Software Engineering (ICSE05), St. Louis,
Missouri, USA, pp. 49-58, 2005.
KIENZLE, J., GUERRAOUI, R. Aop: Does it make sense? The Case of Concurrency and
Failures. In Magnusson, B., editor, ECOOP, volume 2374 of Lecture Notes in Computer
Science, pages 3761. Springer.

242
KRECHETOV, I., TEKINERDOGAN, B., GARCIA, A., CHAVEZ, C., KULESZA, U.
Towards an Integrated Aspect-Oriented Modeling Approach for Software Architecture
Design. In: Aspect-Oriented Modelling Workshop (AOM06), in conjunction with Aspect-
Oriented Software Development Conference (AOSD06), Bonn, Alemanha, 2006.
LARMAN, G. Utilizando UML e Padres Uma Introduo a Anlise e ao Projeto
Orientados a Objetos e ao Processo Unificado. 2. Edio, Bookman, 2004.
LEMOS, O.A., VINCENZI, A.M.R., MALDONAO, J.C., MASIERO, P.C. Teste de Unidade
de Programas Orientados a Aspectos. In Anais do 18. Simpsio Brasileiro de Engenharia
de Software (SBES04) (indicado para best-paper) Braslia, DF, Brasil, 2004.
LEMOS, O.A.L., MALDONADO, J.C., MASIERO, P.C. Data-Flow Integration Testing
criteria for Aspect-Oriented Programs. In: Anais do 1o. Workshop de Desenvolvimento de
Software Orientado a Aspectos (WASP04) realizado em conjunto com o SBES04,
Braslia, DF, Brasil, 2004a.
MENDONA, M., ALENCAR, P., OLIVEIRA, T., COWAN, D. Assisting Aspect-Oriented
Framework Instantiation: Towards Modeling, Transformation and Tool Support. In:
Poster Session of Object-Oriented Programming, Systems, Languages and Applications
(OOPSLA05), San Diego, USA, 2005.
MOREIRA, A., ARAJO, J. Handling Unanticipated Requirements Change with Aspects. In:
Proceedings of Software Engineering and Knowledge Engineering Conference
(SEKE04), Banff, Canada, June, 2004.
MORTENSEN, M., GHOSH, S. Creating Pluggable and Reusable Non-functional Aspects in
AspectC++. In: Proceedings of the 5
th
Workshop on Aspects, Components and Patterns
for Infrastructure Software (ACP4IS06). Workshop of the Aspect-Oriented Software
Development Conference, Bonn, Alemanha, 2006a.
MORTENSEN, M., GHOSH, S. Using Aspects With Object-Oriented Frameworks. In:
Proceedings of the Aspect-Oriented Software Development Conference industry track,
Bonn, Alemanha, 2006b.
OJB. http://db.apache.org/ojb/. (ltimo acesso em 4 de abril de 2006).
PAWLAK, R., DUCHIEN, L., FLORIN G., LEGONG-AUBRY, F., SEINTURIER, L,
MARTELLI, L. A UML Notation for Aspect-Oriented Software Design. In: Proceedings
of Workshop of Aspect Oriented Modeling with UML of Proceedings of Aspect Oriented
Software Development Conference (AOSD), 2002.
PINTO, M.; FUENTES, L.; TROYA, J.M.; FAYAD, M.E. Towards an Aspect Oriented
Framework in the Design of Collaborative Virtual Environments. In: 8 th IEEE
243
Workshop On Future Trends of Distributed Computing Systems (FTDCS). Bologna,
Itlia, novembro 2001a.
PINTO, M.; AMOR, M.; FUENTES, L.; TROYA, J.M. Collaborative Virtual Environment
Development: An Aspect Oriented Approach. In: 21th international Conference on
Distributed Computing Systems Workshops (ICDCSW). Mesa, Arizona, USA, Abril
2001b.
PINTO, M.; FUENTES, L.; FAYAD, M.E; TROYA, J.M. Separation of Coordination in a
Dynamic Aspect Oriented Framework. In: Proceeding of the 1
st
International Conference
on Aspect-Oriented Software Development, April 2002.
PREE, W. Hot-Spot-Driven Development in M. Fayad, R. Johnson, D. Schmidt. Building
Application Frameworks: Object-Oriented Foundations of Framework Design, John
Willey and Sons, p. 379393, 1999.
PREE, W., KOSHIMIES, K. Framelets Small and Loosely Coupled Frameworks. ACM
Computer Surveys, v.32, n.1, pp. 6-10, 2000.
RAMOS, R.A., CAMARGO, V.V., Penteado, R.A.D. Reso da Implementao Orientada a
Aspectos do Padro de Projeto Camada de Persistncia. In: 4
th
Latin American
Conference on Pattern Languages of Programming (Sugarloaf Plop), Fortaleza, 2004.
RASHID, A., CHITCHYAN, R. Persistence as an Aspect. In: Proc. of the 2
nd
International
Conference on Aspect Oriented Software Development (AOSD), BostonUSA, March,
2003.
RASHID, A., SAWYER, P., MOREIRA, A., ARAUJO, J. Early Aspects: A Model for
Aspect-Oriented requirements engineering. In: Joint Intl Conference Requirements
Engineering (RE), Essen, Germany, IEEE, pp 199-202, 2002.
RAUSCH, A., RUMPE, B., HOOGENDOORN, L. Aspect-Oriented Framework Modeling.
In: Proc. of the 4
th
AOSD Modeling with UML Workshop (UML Conference 2003)
October, 2003.
ROCHA, A.D., CAMARGO, V.V., MASIERO, P.C. Uso de Aspectos para Verificar Regras
de Instanciao de Frameworks. RITA Revista de Informtica Terica e Aplicada,
Volume XI, Fascculo 2, pp 9 20, 2004a.
ROCHA, A.D., CAMARGO, V.V., MASIERO, P.C. Uso de Aspectos para Verificar Regras
de Instanciao de Frameworks. In: Relatrio do 1. Workshop Brasileiro de
Desenvolvimento de Software Orientado a Aspectos (WASP04). Workshop realizado em
conjunto com o 18 Simpsio Brasileiro de Engenharia de Software (SBES04), Braslia,

244
DF, Brasil, 2004b (premiado como melhor artigo e convidado para publicao na revista
RITA).
ROSS, D. Structured Analysis: A Language for Communicating Ideas. IEEE Transaction on
Software Engineering, v.3, n.1, 1977.
SHAH, V., HILL, V. An Aspect-Oriented Security Framework: Lessons Learned. In:
Proceedings of AOSDSEC04 (AOSD Technology for Application-Level Security).
Workshop of the Aspect Oriented Software Development Conference, Lancaster, UK,
March, 23, 2004.
SOARES, S. An Aspect-Oriented Implementation Method. Dissertao de Mestrado. Centro
de Informtica (CI), Universidade Federal de Pernambuco (UFPe), Setembro, 2004.
SOARES, S., LAUREANO, E., BORBA, P. Implementing Distribution and Persistence
Aspects with AspectJ. In: Proc. the 17
th
ACM Conference on Object-Oriented
Programming, Systems, Languages, and Applications (OOPSLA), pp 174-190, November,
2002.
SOURCEFOURGE. http://sourceforge.net/. ltimo acesso em 28/07/2006.
STEIN, D., HANENBERB, S., UNLAND, R. Designing Aspect-Oriented Crosscutting in
UML. In: Workshop Aspect-Oriented Modeling with UML, AOSD, Enschede, April, 2002.
SUN MICROSYSTEMS. Java Authentication and Authorization Service.
http://www.java.sun.com/products/jaas. ltimo acesso: 17/05/2006.
SUVE, D., FRAINE, D.B., VANDERPERREN, W. FuseJ: An Architectural description
language for unifying aspects and components. In: Proc. of the 1
st
Workshop on Software
Engineering Properties of Languages for Aspect Technologies (SPLAT05), Chicago,
2005.
SUVE, D.; VANDERPERREN, W.; JONCKERS, V. Jasco: an aspect-oriented approach
tailored for component based software development. In: Aspect Oriented Software
Development (AOSD03), p. 2129, 2003.
SUZUKI, J., YAMAMOTO, Y. Extending UML With Aspects: Aspect Support in the Design
Phase. In: Workshop on Aspect-Oriented Programming (ECOOP), Lisboa, 1999.
TARR, P., OSSHER, H., SUTTON, S. Hyper/JTM : Multi-dimensional Separation of
Concerns for Java. In: Proc. of the 24th International Conference on Software
Engineering. Orlando, Florida, 2002.
VANHAUTE, B., de WIN, B., DECKER, B. Building Frameworks in AspectJ. In: Proc. of
the 15
th
European Conference on Object-Oriented Programming (ECOOP), Separation of
Concerns Workshop. pp. 1-6, June, 2001.
245
YASSIN, A., FAYAD, M.E. Application Frameworks: A Survey, cap. 29 in M. E. Fayad and
R. E. Johnson. Domain-Specific Application Frameworks: Frameworks Experience by
Industry, John Wiley & Sons, p. 615632, 2000.
YODER, J. W., JOHNSON, R. E., WILSON, Q. D. Connection Busines Objects to Relational
Databases. In: Proceedings on the Conference on the Pattern Languages of Programs,
Monticello-IL, EUA. 1998.
ZAKARIA, A.A., HOSNY, H., ZEID, A. A UML Extension for Modelling Aspect-Oriented
Systems. In: Proceedings of Workshop of Aspect Oriented Modeling with UML of Aspect
Oriented Software Development Conference (AOSD) 2002.
ZHAO, J. Data-Flow-Based Unit Testing of Aspect-Oriented Programs. In: Proceedings of
the 27
th
Annual IEEE International Computer Software and Applications Conference,
Dallas, Texas, USA, 2003.
ZHAO, J. Tool Support for Unit Testing of Aspect-Oriented Software. In: OOPSLA 2002
Workshop on Tools for Aspect-Oriented Software Development, Seatle, WA, 2002.
ZHOU Y., RICHARDSON D., ZIV H., Towards a Practical Approach to Test Aspect-
Oriented Software. In: Proc. of the 2004 Workshop on Testing Component-based Systems
(TECOS 2004), Net.ObjectDays, 2004.
ZUBAIROV, R., HANENBERG, S., UNLAND, R. Modularizing Security Related Concerns
in Enterprise Applications A Case Study with J2EE and AspectJ. In: Hirschfeld, R.,
Kowalczyk, R., Polze, A., Weske, M. (eds.). Proceedings of NetObjectDays (NODE 2005)
and GSEM, Erfurt, September, 19-22, LNI p-69, Gesellshcharf fr Informatik, 2005.


246

ANLXO J - DOCUMLN1O DL RLQUISI1OS DO SIS1LMA DL
RLSLRVAS DL UMA RLDL DL HO1LIS

A.1 Descrio Geral do Sistema

O Sistema de Reserva de Hotel consiste em um sistema de gerenciamento das reservas
das acomodaes de um hotel de uma rede de hotis. Atualmente, cada hotel tem seu prprio
sistema, que so incompatveis entre si. No novo sistema a ser construdo, as reservas podem
ser feitas por telefone, ligando diretamente para uma central de reservas ou para o hotel, ou
ento pela Internet.
Cada hotel tem diferentes tipos de acomodao que podem ser reservados por um
cliente, cujos dados devem ser registrados no sistema. O cliente pode confirmar, modificar,
cancelar ou ocupar sua reserva e receber uma acomodao do tipo escolhido, nesta ltima
situao. Uma vantagem do novo sistema ser a possibilidade de oferecer acomodaes em
hotis alternativos quando o hotel desejado j estiver cheio. No hotel, ser possvel fazer as
reservas nos balces de atendimento e nos escritrios. Cada hotel tem um gerente responsvel
por controlar as reservas, mas qualquer usurio autorizado pode faz-las. O tempo desejado
para fazer uma reserva por telefone ou pessoalmente de trs minutos. Para agilizar o
processo, detalhes de clientes que j estiveram no hotel sero armazenados e disponibilizados
para uso. O controle do pagamento das locaes de quarto e taxas por reserva no ocupada
sem cancelamento ser realizado por um sistema de pagamento existente. O hotel possui um
gerente que responsvel pelo gerenciamento do hotel, acomodaes, funcionrios, etc, e um
administrador do Sistema de Reservas que responsvel por gerenciar o sistema, atribuir
permisses de acesso, etc.

A.2 Requisitos Funcionais

A.2.1 Operaes bsicas do sistema

1. O sistema deve permitir a incluso, alterao e remoo de hotis, com os seguintes
atributos: identificao, nome, endereo, telefone, IE.
2. O sistema deve permitir a incluso, alterao e remoo de acomodaes do hotel, com os
seguintes atributos: nmero da acomodao, descrio, tipo de acomodao e situao
atual (vago ou ocupado).
Anexos

248
3. O sistema deve permitir a incluso, alterao e remoo de tipos de acomodao oferecidos
pelo hotel, com os seguintes atributos: cdigo do tipo de acomodao, descrio e preo.
4. O sistema deve permitir a incluso, alterao e remoo de clientes do hotel, com os
seguintes atributos: nome, endereo, cidade, estado, telefone, fax, e-mail e documento de
identificao (CPF e RG).
5. O sistema deve permitir a incluso, alterao e remoo de usurios do sistema, com os
seguintes atributos: nome, login e senha.

A.2.2 Reserva

6. O sistema deve permitir o processamento de reservas de acomodaes de um hotel,
devendo ser registrados os seguintes atributos: identificao do hotel, identificao do
cliente, data de incio da estada, data de fim da estada e tipo de acomodao.
Existe vaga de acomodao no hotel se h pelo menos um tipo de acomodao desejado
disponvel no perodo solicitado e se aps a reserva haver pelo menos um tipo de
acomodao de qualquer tipo disponvel no mesmo perodo.
A deciso se h acomodao disponvel d-se pelo clculo a seguir: R = (A - B > 0) e (Ta
- Tb > 1)
A: total de quartos disponveis de um certo tipo. B: somatria das reservas existentes para
um certo tipo de quarto em um determinado perodo.
Ta: total de quartos (de qualquer tipo). Tb: total de reservas.
OBS1: O Clculo feito para cada dia do perodo. OBS2: No clculo do valor contam-se
as noites dormidas. Se a reserva de 04/02 a 10/02, contam-se os dias de 04 a 09, ou seja,
6 dias.
O sistema deve enviar ao cliente os dados referentes sua reserva e um cdigo da reserva
por e-mail.
7. O sistema deve permitir que os clientes que j confirmaram a reserva no hotel cancelem ou
modifiquem os dados da reserva.
8. O sistema deve permitir o processamento da ocupao da reserva do hotel, iniciando a
estada do cliente no hotel, devendo ser registrados os seguintes atributos: identificao da
reserva e nmero do quarto ocupado.
9. O sistema deve gerar dados referentes s estadas dos clientes para o sistema de faturamento
existente, bem como dos casos em que o cliente no ocupou a reserva sem cancel-la.
Neste ltimo caso cobrado o valor de uma diria do cliente.
Anexos
249
10. Os preos das dirias variam de acordo com o dia da semana e o tipo da acomodao, e
descontos so oferecidos para empresas que possuem convnio com o hotel.
A.2.3 Emisso de relatrios e consultas
11. Consultar se uma acomodao est ocupada ou no.
12. Consultar o nmero de reservas de um certo tipo de acomodao em um certo dia.
13. Listar as reservas de um certo dia/perodo.
A.3 Requisitos No Funcionais
A.3.1 Segurana
14. O sistema deve permitir a autenticao de seus usurios.
15. O sistema deve gerar arquivos de registro das operaes de reserva, alterao de reserva e
cancelamento de reserva realizadas no sistema.
A.3.2 Controle de Acesso
16. O sistema deve oferecer meios para permitir a execuo de operaes de acordo com o
tipo do usurio autenticado no sistema.
17. O sistema deve permitir a atribuio de papis aos usurios do sistema e a atribuio de
direito de acesso a operaes do sistema aos papis.
A.3.3 Persistncia
18. O sistema deve permitir que os dados necessrios para o gerenciamento do hotel sejam
armazenados em um banco de dados.
A.3.4 Desempenho
19. A reserva deve ser feita em menos de 3 minutos (por telefone ou pessoalmente).

A.4 Glossrio
Anexos

250

Anexos
251
ANLXO 2 - IORMULRIO DL CARAC1LRIZAO DO PLRIIL
The purpose of this form is to characterize your computer science background.
Please fill it out truthfully and as completely as possible. Only a confidential ID# will
appear on these pages.
Professional Experience

1) What is your proficiency level in English?

Reading

[ ] basic [ ] medium [ ] advanced [ ] expert

Writing


Listening


2) What is your previous experience with software development in practice? (Check the
right-most item that applies.)
I have
developed
software on
my own
I have developed
software on as part
of a team, as part of
a course
I have developed
software as part of a
team, in industry, for
less than 5 years.
I have developed
software as part
of a team, in
industry, for 5 or
more years.

Please explain your answer. Include the number of months of relevant experience.

a) How many months of experience have you had in manager:
Months of experience: ______ (student) _______ (industry)

b) How many months of experience have you had in analyst:
Months of experience: ______ (student) _______ (industry)

c) How many months of experience have you had in developer (programming):
Months of experience: _____ (student) _______ (industry)

d) How many months of experience have you had in tester:
Months of experience: _______ (student) _______ (industry)

3) How well you know

Anexos

252
a) How well do you know the aspect oriented programming concepts?
1 Expert
2 Advanced
3 Medium
4 Basic
5 None

b) How well do you know Java language?
1 Expert
2 Advanced
3 Medium
4 Basic
5 None

c) How well do you know Aspect J language?
1 Expert
2 Advanced
3 Medium
4 Basic
5 None
Months of experience: ____ (student) _______ (industry)

4) Fraction of programming experience spent
____% in individual effort (alone)
____% in cooperation with others (team)
______% in supervision of other programmers (management)

Programming Language Experience

5) How many programs have you written by yourself of the given sizes using the following
languages?

Number of programs with program size (# of lines)
Programming
Language
>
0
>
100
>
300
>
500
>
1000
>
1500
>
5000
>
1000
0
>
1500
0
Cobol
Pascal
C
C++
Java
Aspect J
Delphi
(other) Clipper

Anexos
253
ANLXO 3 - QJ QULS1IONRIO INDIVIDUAL PARA
PAR1ICIPAN1LS DO LS1UDO DL CASO

Nome:
Idade:

Disciplina que est fazendo:
Data:

Curso:

Nvel:

Sua graduao:

Nvel de conhecimento da linguagem Java:

Nvel de conhecimento da linguagem AspectJ:

Nvel de conhecimento com programao orientada a aspectos:

J implementou algo antes em AspectJ? O que?

Conhece alguma outra linguagem orientada a aspectos?

Q2 Questionrio Individual para Participantes do Estudo
de Caso

Utilize a tabela abaixo para marcar o tempo gasto com cada atividade do
processo de reso do Framework Transversal (FT). O tempo despendido em cada
atividade tambm inclui a compreenso do manual.

Etapa Atividades Tempo despendido
Manual Implementao
data incio Trmino incio Trmino
Escolher variabilidade
Criar a camada de instanciao
Implementar variabilidade
Criar tabela
I
n
s
t
a
n
c
i
a
o

Preencher a tabela
Definir mapeamento OO-
Relacional

Definir as variabilidades de
conexo

Determinar a conexo
Identificar ponto de juno
C
o
m
p
o
s
i
o

Fornecer regras de composio

Anexos

254
Anote tambm em local separado o tempo gasto com quaisquer outras
atividades relacionadas com o estudo de caso, por exemplo: o estudo de um
determinado comando da linguagem AspectJ.

Responda as questes abaixo:

Em relao aos manuais

1) Em que nvel o manual de reso auxilia o processo?

2) Voc sentiu falta de alguma outra fonte de documentao durante o processo
de reso, por exemplo diagramas de classes, de seqncia, use-cases, etc ?

3) Em que nvel o documento que descreve as alternativas do padro auxilia na
escolha das alternativas de composio? O que esse documento poderia
conter para auxiliar ainda mais a identificao dos pontos de juno ideais no
cdigo-base?

Em relao ao processo de reso

4) Em qual das atividades (dentro de cada etapa) voc obteve mais problemas
de implementao e porque? Quais foram esses problemas?

5) Voc acha que as alternativas de composio do padro so suficientes para
todos os casos de acoplamento? Justifique sua resposta.

6) Em que nvel de dificuldade vc categoriza a atividade identificar ponto de
juno?

7) Cite algo que poderia apoiar de forma mais direta a atividade identificar ponto
de juno (manuais, ferramentas, diretrizes).

8) Antes de encontrar o ponto de juno ideal para o acoplamento, quais foram
suas tentativas? Tentou acoplar em local errado?
Anexos
255
ANLXO 4 - RLLA1RIO DL IMPLLMLN1AO DO
IRAMLWORK DL PLRSIS1LNCIA L SLGURANA ORILN1ADO A
ASPLC1OS

Disciplina: Seminrios Avanados em Engenharia de Software
Professor: Paulo Csar Masiero
Aluno:

1 O Processo

a) O processo proposto representa corretamente as atividades que voc realiza ou deveria
ser modificado? Neste caso, que atividades voc acrescentaria ou removeria?

b) Qual foi o grau de iteratividade do processo realmente requerido por voc? Essa
iteratividade deveria ser representada no processo proposto?

c) Qual a sua opinio sobre a agilidade/eficincia do processo?

2 Tempo

a) Marque o tempo gasto em cada uma das fases do processo.

b) Relate os tipos de erros e o tempo que foi gasto para solucion-los. Relate se os erros
foram oriundos de problemas do manual, do engenheiro de aplicao (voc), ou de
problemas do framework.

3 - Experincia com o framework de persistncia

a) Relate sobre a facilidade/dificuldade de instanciao.

b) muito restrito ou as funcionalidades (mtodos) que ele fornece so suficientes para o
tipo de aplicao que est sendo desenvolvida?

c) H necessidade de mais variabilidades? Quais?

d) Voc acha que ele agiliza o desenvolvimento ?

4 - Experincia com o framework de segurana

a) fcil ou difcil de instanciar?

b) Ele muito restrito ou as funcionalidades (mtodos) que ele fornece so suficientes
para o tipo de aplicao que est sendo desenvolvida?
Anexos

256

c) H necessidade de mais variabilidades? Quais?

d) O sistema do administrador tem funcionalidades suficientes para gerenciar os papis
dos usurios?

e) H como burlar o controle de acessso que feito s operaes?

5 - O manual

a) O Manual d apoio ao desenvolvimento em cada uma dessas fases?

b) Que fase ele apia melhor?

c) O que poderia ser feito para melhor-lo?

6 - Diversos

a) Relate quaisquer outros problemas ou vantagens que voc tenha percebido em
relao ao desenvolvimento de uma aplicao com frameworks orientados a
aspectos.

b) Voc acha que a manuteno ser melhorada com o uso desses frameworks? E
quanto evoluo da aplicao e dos frameworks?

Tese Valter Final

Enviado por

Dados do documento

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

Tese Valter Final

Enviado por

Direitos autorais:

Formatos disponíveis

Frameworks transversais: definioes, classificaoes,

arquitetura e utilizaao em um processo de

Você também pode gostar