A Model-Driven Software Reuse Approach (in portuguese)

More documents

Recommendations

Info

182 o resultado da evolução dos estudos utilizados como base para testar e refinar as atividades da abordagem, conforme descrito na Seção 4.3. O segundo estudo foi realizado na indústria, durante um estágio de doutorado, e a escolha do domínio envolvido, de aplicações distribuídas baseadas em computação em nuvem, não foi feita pelo autor desta tese, mas sim pelos líderes do grupo no qual o estágio foi realizado. O terceiro estudo, também realizado na indústria, envolveu o domínio de eventos científicos, e a escolha se deu por conveniência e proximidade da empresa ao grupo de pesquisa. Os estudos são comparativos, ou seja, visam comparar os resultados do desenvolvimento realizado sem a abordagem com o desenvolvimento realizado com a abordagem. Para essa comparação, foram utilizadas implementações de exemplo desenvolvidas antes do uso da abordagem, que não contemplavam modelos ou qualquer tipo de artefato relacionado ao MDD, e as implementações desenvolvidas com a abordagem, que incluem uma arquitetura preparada para o MDD, além dos artefatos específicos para este contexto, como DSLs, transformações e geradores de código. A seguir são apresentados mais detalhes sobre cada estudo. 8.2.1 Autoria de conteúdo para a Web O primeiro estudo foi realizado em ambiente acadêmico, e envolveu o domínio de aplicações de autoria de conteúdo para a Web. São aplicações onde um administrador publica conteúdo a ser visualizado por muitos usuários, como por exemplo portais de notícias, páginas pessoais, fóruns e blogs. Trata-se de um domínio técnico, envolvendo os requisitos de persistência e navegação na Web. Neste estudo, as linguagens específicas de domínio, geradores, a arquitetura e a implementação de referência foram desenvolvidos a partir do zero, utilizando a abordagem definida nesta tese. Foi executado pelo autor desta tese, com a ajuda de especialistas de domínio. Inicialmente, foram realizados estudos sobre as tecnologias de implementação necessárias, e em seguida a abordagem foi aplicada no desenvolvimento dos artefatos do domínio. Foi desenvolvida uma infraestrutura composta de artefatos de software gerados e não-gerados, em uma arquitetura em três camadas. Foram desenvolvidas quatro linguagens específicas de domínio: uma linguagem visual para persistência, uma linguagem textual para navegação, uma linguagem textual para a produção de relatórios e uma linguagem visual para configuração das features presentes no produto. Também foram desenvolvidas transformações e geradores de código que produzem aplicações completas, segundo as especificações dos
modelos. O Quadro 14 mostra um resumo dos dados relevantes sobre este estudo. Domínio Autoria de conteúdo para Web Local ICMC/USP - São Carlos/SP Participantes 1 (autor) Tempo total 3 meses (dedicação integral) Número de DSLs 4 (persistência, navegação, relatórios e features) Número de artefatos de geração (transformações e geradores) 38 Tamanho total (LOC) artefatos de geração 1610 Tamanho total (LOC) implementação de referência 5941 Número de features 15 do domínio Tecnologias de implementação Tecnologias MDD Apache Tomcat, MySQL, Java, JSP, JSTL, Servlets, XML, SQL, Eclipse (versão Ganymede) + WebTools plug-in Eclipse (versão Ganymede) EMF (Eclipse Modeling Framework) GMF (Graphical Modeling Framework) JET (Java Emitter Templates) openArchitectureWare Quadro 14: Dados sobre o estudo envolvendo o domínio de autoria de conteúdo para Web 8.2.2 Aplicações distribuídas baseadas em computação em nuvem O segundo estudo foi realizado em ambiente industrial, envolvendo o domínio de aplicações distribuídas baseadas em computação em nuvem (LUCRÉDIO; JACKSON; SCHULTE, 2008). As principais características deste domínio são o alto grau de incerteza sobre a topologia da aplicação, a heterogeneidade dos ambientes e infraestrutura e o alto grau de cooperação entre os componentes distribuídos. Este estudo foi realizado durante um estágio de doutorado realizado pelo autor da tese nos laboratórios da Microsoft Research, em Redmond, Estados Unidos (LUCRÉDIO; JACKSON; SCHULTE, 2008). Este domínio já vinha sendo explorado pelos pesquisadores da Microsoft Research, que desenvolveram uma teoria baseada em modelagem de negócios e um conjunto de três linguagens específicas para este objetivo (JACKSON; SCHULTE, 2008): uma linguagem visual para descrever os dados do sistema, uma linguagem visual para descrever as características dos tipos de elementos distribuídos, sua conectividade e quais dados possuem, e uma linguagem visual para descrever a semântica das operações de manipulação dos dados. O aspecto mais interessante desta especificação é que os modelos de dados e operações não precisam se preocupar com a localização dos dados e nem que tipo de elemento distribuído é responsável por sua manutenção. 183
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 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 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)

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?