A Model-Driven Software Reuse Approach (in portuguese)

More documents

Recommendations

Info

208 DSL. Um domínio no Draco inclui um interpretador semântico (parser), que incorpora as regras gramaticais da linguagem. Desta forma, ao se construir um sistema para esse domínio, um engenheiro de software pode utilizar essa DSL. Por exemplo, considere um analista do domínio de jogos eletrônicos. Ele define elementos como “placar”, “comando”, “fase”, “jogador”, entre outros, e os descreve utilizando regras gramaticais, que servem para a criação de um interpretador (parser). O analista de um sistema utiliza esses elementos para construir seu próprio jogo, criando elementos como “Jogador 1”, “Jogador 2”, “comandoDireita”, “comandoEsquerda”, etc. Uma possível gramática para essa DSL, onde um jogo envolve vários jogadores, seria: Dessa forma, um novo jogo poderia ser definido por meio dessa linguagem, por exemplo: No Draco, o analista do domínio também pode construir transformações que permitem que os elementos criados pelo analista do sistema sejam automaticamente transformados em domínios intermediários, até eventualmente chegar em linguagem executável. É o que acontece quando, por exemplo, se deseja obter um modelo orientado a objetos deste jogo, para posteriormente implementá-lo utilizando uma linguagem de programação orientada a objetos. No Draco, as transformações se baseiam nas regras gramaticais das linguagem dos domínios, interpretadas pelo seu próprio parser. Por isso é necessário existir uma gramática para a linguagem de origem e uma gramática para a linguagem destino. Neste caso, seria necessária uma gramática para esse modelo orientado a objetos intermediário, que poderia ser parecida com:
Uma transformação automática deste jogo para este modelo orientado a objetos poderia gerar algo como: De forma similar, com base na definição do domínio para uma linguagem executável, como por exemplo Java, poderia ser definida uma transformação que gerasse o seguinte código para este jogo: 209
Page 1 and 2:
Daniel Lucrédio Uma Abordagem Orie
Page 3 and 4:
Agradecimentos Agradeço à minha o
Page 5 and 6:
“Academic organizations in comput
Page 7 and 8:
Abstract Software reuse aims at inc
Page 9 and 10:
20 Padrão visitante sendo aplicado
Page 11 and 12:
Lista de Quadros 1 Identificação
Page 13 and 14:
GUI Graphical User Interface / Inte
Page 15 and 16:
Sumário 1 Introdução 19 1.1 A te
Page 17:
10.1 Principais contribuições . .
Page 20 and 21:
20 que uma organização alcance os
Page 22 and 23:
22 ao ponto de não sermos mais cap
Page 24 and 25:
24 quando comparado com um processo
Page 26 and 27:
26 orientado a modelos. Nesta pesqu
Page 29 and 30:
2 Conceitos envolvidos Esta tese en
Page 31 and 32:
Dessa forma, o que é necessário
Page 33 and 34:
maior em determinada parte do proce
Page 35 and 36:
processo são necessários para que
Page 37 and 38:
ser atualmente um artefato extremam
Page 39 and 40:
apreciada por desenvolvedores. É p
Page 41 and 42:
2.2.1 Conceitos do desenvolvimento
Page 43 and 44:
eutilizar também o código a ele a
Page 45 and 46:
tarefa complexa. Finalmente, é nec
Page 47 and 48:
O MOF consiste em um padrão orient
Page 49 and 50:
2.2.2.3 Abordagem Eclipse Figura 5:
Page 51 and 52:
Outro projeto, que fazia parte do G
Page 53 and 54:
2.2.3 O processo de desenvolvimento
Page 55:
2.3 Considerações finais Neste ca
Page 58 and 59:
58 • Na criação de um projeto q
Page 60 and 61:
60 • Categorias de features e ano
Page 62 and 63:
62 linguagem específica para o dom
Page 64 and 65:
64 caso um deles não seja capaz de
Page 66 and 67:
66 O segundo elemento é o template
Page 69 and 70:
4 Visão geral da abordagem Neste c
Page 71 and 72:
ferramentas capazes de criar modelo
Page 73 and 74:
em estado inicial antes de uma dete
Page 75 and 76:
Figura 9: Sugestão de modelo de pr
Page 77 and 78:
pelos stakeholders e a existência
Page 79 and 80:
selecionadas para aquele módulo, t
Page 81 and 82:
É importante ressaltar que nem sem
Page 83 and 84:
- ENG8 - Desenvolver metamodelo cen
Page 85 and 86:
5 Análise de domínio orientada a
Page 87 and 88:
com exatidão o escopo a ser desenv
Page 89 and 90:
e pelas condições de mercado, dei
Page 91 and 92:
aplicações. Neste mapa, colunas e
Page 93 and 94:
A Figura 11 mostra o modelo de feat
Page 95 and 96:
Mesmo um caso de mudança pode sofr
Page 97 and 98:
Supondo que um caso de uso UC001 po
Page 99 and 100:
Entradas: Informações sobre siste
Page 101 and 102:
de nível de confiança (Sub-ativid
Page 103 and 104:
é consultado, além das documenta
Page 105 and 106:
• Como a ferramenta se enquadra n
Page 107 and 108:
Quadro 7: Documentação do nível
Page 109 and 110:
tecnologia no desenvolvimento, e re
Page 111 and 112:
Neste caso, o subdomínio de cadast
Page 113:
Produto de trabalho Descrição Est
Page 116 and 117:
116 completamente. Diferentes mecan
Page 118 and 119:
118 de produtos (WEISS et al., 2008
Page 120 and 121:
120 PD.4), de forma a identificar n
Page 122 and 123:
122 • Variabilidade em forma de D
Page 124 and 125:
124 Saídas: PT.8. Táticas e padr
Page 126 and 127:
126 Features alternativas: estas s
Page 128 and 129:
128 selecionada (linha 3). Opcional
Page 130 and 131:
130 Em cada decorator implementa-se
Page 132 and 133:
132 que pode ser inserido em outros
Page 134 and 135:
134 Sub-atividade PD.3.3. Padrões
Page 136 and 137:
136 isto corresponde à criação,
Page 138 and 139:
138 aquele módulo específico, con
Page 140 and 141:
140 • Número de cenários indire
Page 142 and 143:
142 Produto de trabalho Descrição
Page 144 and 145:
144 domínio para reutilização s
Page 146 and 147:
146 A fase de implementação segue
Page 148 and 149:
148 há alguma variabilidade que n
Page 150 and 151:
150 ser realizado exclusivamente de
Page 152 and 153:
152 • Sub-features podem também
Page 154 and 155:
154 pode garantir que o comportamen
Page 156 and 157:
156 D2. Para cada feature opcional,
Page 158 and 159: 158 • Remoção de funcionalidade
Page 160 and 161: 160 Por exemplo, pode-se embutir o
Page 162 and 163: 162 identificação das variabilida
Page 164 and 165: 164 Asset Specifications ou Especif
Page 166 and 167: 166 4. Especificação dos parâmet
Page 168 and 169: 168 Produto de trabalho Descrição
Page 170 and 171: 170 definidos os objetivos da avali
Page 172 and 173: 172 Existem diferentes métricas vo
Page 174 and 175: 174 de modelagem. Como o objetivo
Page 176 and 177: 176 uma medida instantânea como um
Page 178 and 179: 178 NR = 13,13 + 8,88 + 8 + 8,2 4 =
Page 180 and 181: 180 e projeta-se um ou mais experim
Page 182 and 183: 182 o resultado da evolução dos e
Page 184 and 185: 184 A teoria diz que é possível g
Page 186 and 187: 186 Após o treinamento, a equipe u
Page 188 and 189: 188 Dado um conjunto de dados segui
Page 190 and 191: 190 gerado e não-gerado, porém de
Page 192 and 193: 192 primeira explicação é a de q
Page 194 and 195: 194 A porcentagem de reutilização
Page 196 and 197: 196 Figura 38: Distribuições do
Page 198 and 199: 198 código para cada elemento de e
Page 200 and 201: 200 de reutilização com geração
Page 202 and 203: 202 Figura 42: Efeito da abordagem
Page 204 and 205: 204 protótipos executáveis desenv
Page 207: 9 Trabalhos relacionados As idéias
Page 211 and 212: correspondente às linguagens de pr
Page 213 and 214: Weis, Ulbrich e Geihs (2003) aprese
Page 215 and 216: ase em exemplos do código a ser ge
Page 217 and 218: programação empregada por uma tec
Page 219 and 220: (PÉREZ-MARTÍNEZ; SIERRA-ALONSO, 2
Page 221 and 222: Bierhoff, Liongosari e Swaminathan
Page 223 and 224: Monperrus et al. (2008) argumentam
Page 225 and 226: estão fixadas na UML e na visão 4
Page 227 and 228: 10 Conclusões Reutilização de so
Page 229 and 230: A realização dos estudos empíric
Page 231 and 232: desenvolvimento de transformações
Page 233: Esta abordagem é um passo inicial
Page 236 and 237: 236 ANTKIEWICZ, M.; CZARNECKI, K. F
Page 238 and 239: 238 COOK, S. et al. Domain-Specific
Page 240 and 241: 240 FENTON, N.; PFLEEGER, S. L. Sof
Page 242 and 243: 242 JACOBSON, I.; GRISS, M.; JONSSO
Page 244 and 245: 244 LEE, J.; MUTHIG, D. Feature-ori
Page 246 and 247: 246 MOHAGHEGHI, P.; DEHLEN, V. Wher
Page 248 and 249: 248 POULIN, J.; CARUSO, J.; HANCOCK
Page 250 and 251: 250 TAULAVUORI, A.; NIEMELA, E.; KA
Page 253 and 254: APÊNDICE A -- Técnicas para reuti
Page 255 and 256: grande número de partes inter-rela
Page 257 and 258: Linguagens específicas de domínio
Page 259 and 260:
genéricas (que oferecem soluções
Page 261 and 262:
• Para os casos de DSLs executáv
Page 263 and 264:
Programação generativa “Program
Page 265 and 266:
Abstração: conforme já discutido
Page 267 and 268:
A utilização de um framework é n
Page 269 and 270:
tecnologias. As principais atividad
Page 271 and 272:
APÊNDICE B -- Relação entre a ab
Page 273 and 274:
das atividades, e um conjunto de po
Page 275 and 276:
necessidades futuras em termos de a
Page 277 and 278:
(independentes de plataforma) e esp
Page 279 and 280:
elacionamentos entre estas entidade
Page 281:
do domínio, definição do glossá
Page 284 and 285:
284 identificar uma relação diret
Page 286 and 287:
286 P:O formato de documentação p
show all

A Model-Driven Software Reuse Approach (in portuguese)

Create successful ePaper yourself

Delete template?

Save as template?