A Model-Driven Software Reuse Approach (in portuguese)

More documents

Recommendations

Info

270 Abstração Seleção Adaptação Integração Encapsulamento e utilização Navegação e busca Parametrização ou Acoplamento de interfaces providas com de interfaces bem definidas automática modificação interna requeridas Desenvolvimento Baseado em Componentes Automatizada através de um compilador Parâmetros definidos na linguagem Consulta à gramática ou manual da linguagem Análise de um domínio de problema Não existe quando é gerado um programa completo. Porém, podem ser necessárias modificações, quando é gerada apenas Produção da entrada do gerador Escolha de um gerador apropriado Definição do formato de entrada (DBC) Linguagens Específicas de Domínio (DSL) Programação Generativa parte de um programa Normalmente não é um problema, pois o framework é uma aplicação semi-pronta Instanciação, através dos “pontos variáveis” e Escolha do framework adequado Adaptação do restante do sistema “ganchos” Adaptação do padrão para a situação Mudanças nos artefatos recuperados, para atender a novos requisitos ou novas tecnologias Frameworks Representação do domínio, destacando os “pontos variáveis” e “ganchos” Padrões Generalização de soluções De forma gradual, o sistema é reconstruído aos poucos, com cada módulo sendo integrado separadamente Busca por um padrão para recorrentes um determinado problema Engenharia Reversa Seleção dos artefatos a serem modificados Reengenharia de software Quadro 17: Resumo das principais técnicas relacionadas aos conceitos básicos da reutilização de software
APÊNDICE B -- Relação entre a abordagem e modelos de maturidade Neste apêndice são descritos em detalhes as práticas do modelo de maturidade em reutilização proposto por Garcia et al. (2007, 2008) e do modelo de maturidade em MDD definido pela iniciativa ModelWare (MODELWARE, 2006d). Também discute-se a relação entre esses modelos de maturidade e a abordagem definida nesta tese. Em cada prática é indicado um símbolo, sendo que o símbolo indica que a prática está presente na abordagem, e o símbolo indica que a prática está ausente da abordagem. Uma breve explicação, destacada em negrito, descreve o raciocínio por trás da presença ou ausência da prática na abordagem. É importante ressaltar que não foi feita uma análise rigorosa de aderência aos modelos de maturidade, analisando-se por exemplo as características principais dos produtos de trabalho e atividades da abordagem e comparando-se com os elementos de processo descritos nos modelos. O foco aqui foi oferecer uma visão mais ampla sobre o escopo e abrangência da abordagem, frente ao que existe na literatura com relação às atividades e práticas relacionadas à reutilização e MDD, além de oferecer uma descrição mais detalhada dos modelos de maturidade. Modelo de maturidade em reutilização de software (GARCIA et al., 2007, 2008) • Nível 1 - Incompleto: neste nível, apenas o desenvolvimento de software tradicional é realizado. Práticas de reutilização são usadas esporadicamente ou mesmo ignoradas e desencorajadas pela gerência. Reutilização é fruto de esforço individual, e os custos da reutilização são desconhecidos. Não existem práticas definidas para este nível; • Nível 2 - Básico: este nível é caracterizado pela utilização básica de artefatos com potencial de reutilização. Engloba algumas atividades básicas orientadas à reutilização, e a implementação do domínio de forma direta, sem uma preocupação com análise e projeto mais voltados à reutilização; 271
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 and 208:
9 Trabalhos relacionados As idéias
Page 209 and 210:
Uma transformação automática des
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: tecnologias. As principais atividad
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?