A Model-Driven Software Reuse Approach (in portuguese)

More documents

Recommendations

Info

106 Quadro 6: Documentação do subdomínio de navegação interação deverá ser refinada, incluindo uma definição mais detalhada da interface entre os artefatos gerados para este subdomínio e outros artefatos. Atividade AD.4. Validação e documentação do domínio Papéis: analista do domínio, especialista do domínio Entradas: Informações sobre sistemas do domínio, Conhecimento do especialista, Informações sobre stakeholders, PT.1.Inicial. Planejamento do domínio, PT.2.Inicial. Mapa de aplicações, PT.3.Inicial. Modelagem do domínio, PT.3.Inicial. Candidatos a subdomínio. Saídas: PT.1.Validado. Planejamento do domínio, PT.2.Validado. Mapa de aplicações, PT.3.Validado. Modelagem do domínio e PT.4.Validado. Candidatos a subdomínio. Descrição: antes do modelo do domínio ser utilizado, ele precisa ser validado e documentado. A documentação já foi iniciada durante as atividades anteriores. Nesta abordagem, as features são documentadas segundo o formato descrito por Czarnecki e Eisenecker (2000), que inclui a sua descrição semântica, o raciocínio, exemplo de aplicação, restrições, e outras informações (ALMEIDA et al., 2006). Em seguida, é feita a validação do domínio. O analista de domínio verifica homônimos e sinônimos, com o objetivo de reduzir a ambiguidade. Em seguida, o domínio é validado
Quadro 7: Documentação do nível de confiança dos subdomínios identificados com relação às informações dos stakeholders, os requisitos iniciais e demais documentos relacionados. Atividade AD.5. Decisão sobre inclusão/exclusão de subdomínios Papéis: analista do domínio, especialista do domínio Entradas: Informações sobre sistemas do domínio, Conhecimento do especialista, Informações sobre stakeholders, PT.1.Validado. Planejamento do domínio, PT.2.Validado. Mapa de aplicações, PT.3.Validado. Modelagem do domínio, PT.4.Validado. Candidatos a subdomínio. Saídas: PT.5. Histórico de decisões sobre inclusão/exclusão de subdomínios. Descrição: nesta atividade, o analista do domínio, junto com o especialista e os demais stakeholders, analisam os subdomínios identificados com o objetivo de determinar se os mesmos serão incluídos nas fases subsequentes de projeto e implementação. Essa decisão deve levar em consideração o nível de confiança dos subdomínios candidatos, e portanto a existência de linguagens, ferramentas e outros indícios de sua maturidade, seus relacionamentos com os demais elementos do domínio, e outros fatores externos, incluindo os objetivos de negócio e condições de mercado. A abordagem baseia-se num processo iterativo, e alguns subdomínios podem estar mais 107
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: • Como a ferramenta se enquadra n
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 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?