Suporte ao uso de frameworks orientados a objetos com base no histórico do desenvolvimento de aplicações

Texto

(1)UNIVERSIDADE FEDERAL DE SANTA CATARINA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. Evandro César Freiberger. SUPORTE AO USO DE FRAMEWORKS ORIENTADOS A OBJETOS COM BASE NO HISTÓRICO DO DESENVOLVIMENTO DE APLICAÇÕES. Dissertação submetida à Universidade Federal de Santa Catarina como parte dos requisitos para a obtenção do grau de Mestre em Ciência da Computação.. Ricardo Pereira e Silva (orientador). Florianópolis, dezembro de 2002.

(2) ii. SUPORTE AO USO DE FRAMEWORKS ORIENTADOS A OBJETOS COM BASE NO HISTÓRICO DO DESENVOLVIMENTO DE APLICAÇÕES. Evandro César Freiberger. Esta Dissertação foi julgada adequada para obtenção do título de Mestre em Ciência da Computação Área de Concentração e aprovada em sua forma final pelo Programa de Pós-Graduação em Ciência da Computação. Prof. Fernando A. O. Gauthier, Dr. (Coordenador). Ricardo Pereira e Silva, Dr. (orientador). Banca Examinadora Leandro José Komosinski, Dr.. Roberto Tom Price, Dr.. Rosvelter Coelho da Costa, Dr.. Vitório Mazzola, Dr..

(3) iii. AGRADECIMENTOS. Ao meu orientador, professor Ricardo Pereira e Silva, pela dedicação, competência e entusiasmo com o trabalho. Fico muito feliz por ter tido a oportunidade de trabalharmos juntos. A minha esposa, Wannessa pelo companheirismo, pelas opiniões e colaborações nesse trabalho. O melhor desse trabalho foi fazê-lo junto com você. A minha mãe Rosi e ao meu pai Waldemar pelo que sou hoje, e pela compreensão frente à ausência durante o período desse trabalho. A minha sogra Elza pela sua dedicação nesse período. A UNIRONDON pela iniciativa de viabilizar esse mestrado fora de sede. A Universidade Federal de Santa Catarina – em particular ao Departamento de Informática e Estatística por ter viabilizado esse mestrado..

(4) iv. SUMÁRIO. LISTA DE FIGURAS ......................................................................................VIII LISTA DE QUADROS .......................................................................................IX LISTA DE GRÁFICOS ......................................................................................XI RESUMO ..........................................................................................................XIII ABSTRACT ......................................................................................................XIV 1. INTRODUÇÃO............................................................................................. 15. 2. PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ................... 18 2.1. INTRODUÇÃO ........................................................................................... 18. 2.2. QUALIDADE DE SOFTWARE ...................................................................... 19. 2.3. MODELO DE DESENVOLVIMENTO ORIENTADO A OBJETOS ........................ 20. 2.3.1. Características do modelo orientado a objetos .............................. 21. 2.3.2. Mecanismos de suporte a reutilização............................................ 24. 2.3.3. Tipos de Artefatos de Software Reutilizáveis.................................. 26. 2.3.4. Dificuldades do modelo orientado a objetos .................................. 28. 2.4 3. CONCLUSÃO............................................................................................. 28. FRAMEWORKS ORIENTADOS A OBJETOS ....................................... 30 3.1. INTRODUÇÃO ........................................................................................... 30. 3.2. CONCEITO ................................................................................................ 30. 3.3. TIPOS DE FRAMEWORKS ........................................................................... 30. 3.4. NÍVEIS DE REUSO NO FRAMEWORK .......................................................... 32. 3.5. DESENVOLVIMENTO DE FRAMEWORK ...................................................... 33. 3.6. DOCUMENTAÇÃO DE FRAMEWORKS ........................................................ 36. 3.7. USO DE PADRÕES DE PROJETO NO FRAMEWORK ....................................... 37. 3.8. CICLO DE VIDA DE FRAMEWORK .............................................................. 38. 3.9. USO DE FRAMEWORKS ORIENTADOS A OBJETOS ..................................... 40. 3.9.1. Propostas de metodologia de uso de frameworks .......................... 42. 3.10. COMO OBTER INFORMAÇÕES DO PROJETO DO FRAMEWORK ................. 45. 3.11. ASPECTOS DE QUALIDADE DE FRAMEWORKS ORIENTADOS A OBJETOS46. 3.12. CONCLUSÃO......................................................................................... 48.

(5) v. 4. 5. DESCRIÇÃO DO AMBIENTE SEA.......................................................... 50 4.1. INTRODUÇÃO ........................................................................................... 50. 4.2. DIAGRAMA DE CASOS DE USO ................................................................. 51. 4.3. DIAGRAMAS DE ATIVIDADES ................................................................... 51. 4.4. DIAGRAMAS DE CLASSES ......................................................................... 52. 4.5. DIAGRAMAS DE SEQÜÊNCIA .................................................................... 54. 4.6. DIAGRAMAS DE TRANSIÇÃO DE ESTADOS ................................................ 55. 4.7. DIAGRAMA DE CORPO DE MÉTODO ......................................................... 55. 4.8. CARACTERÍSTICAS IMPORTANTES DO AMBIENTE SEA............................. 58. 4.9. CONCLUSÃO............................................................................................. 59. MEDIDAS APLICADAS SOBRE O HISTÓRICO DE USO DE. FRAMEWORKS .......................................................................................................... 60 5.1. INTRODUÇÃO ........................................................................................... 60. 5.2. RESTRIÇÕES IMPOSTAS PELO PROJETO DO FRAMEWORK........................... 61. 5.3. QUANTIFICAÇÃO DE PROPORÇÃO DE SOFTWARE PRODUZIDO E REUSADO. 62. 5.3.1. Avaliações de reuso de classes do framework pelas aplicações .... 63. 5.3.2. Avaliações de reuso de métodos do framework pelas aplicações .. 66. 5.3.3. Avaliações de reuso de atributos do framework............................. 69. 5.3.4. Avaliações de reuso de comandos do framework ........................... 71. 5.4. 5.4.1. Avaliações quanto à especialização de classes do framework....... 74. 5.4.2. Avaliações quanto à sobrescrita de métodos do framework .......... 75. 5.4.3. Avaliações dos comandos sobrescritos do framework ................... 77. 5.5. QUANTIFICAÇÃO DE REDEFINIÇÕES NO USO DE FRAMEWORKS ................. 78. 5.5.1. Avaliações quanto à “redefinibilidade” de classes do framework 78. 5.5.2. Avaliações quanto à sobrescrita de métodos do framework .......... 80. 5.6 6. QUANTIFICAÇÃO DE ESPECIALIZAÇÃO NO USO DE FRAMEWORKS ............. 74. CONCLUSÃO............................................................................................. 84. FERRAMENTA DE APOIO AO USO DE FRAMEWORKS ................. 85 6.1. INTRODUÇÃO ........................................................................................... 85. 6.1.1 6.2. Trabalhos Correlatos...................................................................... 86. ESPECIFICAÇÃO DA FERRAMENTA ............................................................ 92. 6.2.1. Extração dos dados das especificações .......................................... 93.

(6) vi. 6.2.2. Estrutura de classes ........................................................................ 95. 6.2.3. Armazenamento dos dados das especificações............................... 99. 6.2.4. Recuperar/Avaliar os dados das especificações........................... 101. 6.3. 7. 6.3.1. Resultados no formato de relatório .............................................. 108. 6.3.2. Resultados no formato de registros .............................................. 109. 6.4. FERRAMENTA DE VISUALIZAÇÃO GRÁFICA ............................................ 110. 6.5. CONCLUSÃO........................................................................................... 111. ESTUDO DE CASO ................................................................................... 112 7.1. INTRODUÇÃO ......................................................................................... 112. 7.2. ESPECIFICAÇÃO DO FRAMEWORK DE JOGOS ........................................... 113. 7.2.1. Diagrama de Casos de Uso .......................................................... 113. 7.2.2. Diagrama de Atividades ............................................................... 114. 7.2.3. Diagramas de classes ................................................................... 114. 7.2.4. Diagramas de seqüência............................................................... 119. 7.3. AVALIAÇÃO DA PROPORÇÃO DE SOFTWARE PRODUZIDO E REUSADO ..... 123. 7.3.1. Avaliações de reuso de classes do framework.............................. 123. 7.3.2. Avaliações de reuso de métodos do framework............................ 128. 7.3.3. Avaliações de reuso de atributos do framework........................... 133. 7.3.4. Avaliações de reuso de comandos do framework ......................... 137. 7.4. QUANTIFICAÇÃO DE ESPECIALIZAÇÃO NO USO DO FRAMEWORK ............ 142. 7.4.1. Avaliações quanto à especialização de classes ............................ 142. 7.4.2. Avaliações quanto à sobrescrita de métodos................................ 144. 7.4.3. Avaliações dos comandos definidos nos métodos......................... 147. 7.5. QUANTIFICAÇÃO DE REDEFINIÇÕES NO USO DO FRAMEWORK ................ 149. 7.5.1. Avaliações quanto à “redefinibilidade” de classes...................... 149. 7.5.2. Avaliações quanto à sobrescrita de métodos do framework ........ 152. 7.6. 8. TIPOS DE RESULTADOS OBTIDOS DA FERRAMENTA ................................. 107. CONCLUSÃO........................................................................................... 160. 7.6.1. Aspecto de reuso de artefatos do framework................................ 160. 7.6.2. Aspecto de especialização de artefatos do framework ................. 160. 7.6.3. Aspecto de sobrescrita de artefatos do framework (previsão) ..... 161. CONCLUSÃO ............................................................................................. 163.

(7) vii. 8.1. RESULTADOS OBTIDOS .......................................................................... 164. 8.2. LIMITAÇÕES ........................................................................................... 165. 8.3. TRABALHOS FUTUROS ........................................................................... 165. 8.4. CONSIDERAÇÕES FINAIS ........................................................................ 166. BIBLIOGRAFIA ............................................................................................... 167 ANEXO – PARTE DA ESPECIFICAÇÃO DOS JOGOS ............................ 171 Diagramas de classes dos jogos ................................................................ 171 Diagramas de corpo de métodos do framework de jogos.......................... 175.

(8) viii. LISTA DE FIGURAS Figura 3.1 – Nível de reuso em um framework [LAJ94]..............................................................................................33 Figura 3.2 - Desenvolvimento de framework através de aplicações tomadas como exemplo.......................................34 Figura 3.3 – Desenvolvimento de framework a partir de outros frameworks ...............................................................36 Figura 3.4 – Desenvolvimento de frameworks a partir de padrões...............................................................................38 Figura 3.5 – Ciclo de vida de um framework ...............................................................................................................39 Figura 3.6 – Papéis dos desenvolvedores no processo de desenvolvimento com framework ......................................40 Figura 3.7 – Fases de desenvolvimento de aplicações padrões verso uso de frameworks ...........................................43 Figura 4.1 – Estrutura do ambiente SEA[SIL00]..........................................................................................................50 Figura 4.2 - Exemplo de Diagrama de Caso de Uso.....................................................................................................51 Figura 4.3 - Exemplo de Diagrama de Atividade .........................................................................................................52 Figura 4.4 -Exemplo de Diagrama de Classe................................................................................................................53 Figura 4.5 - Exemplo de Diagrama de Seqüência.........................................................................................................54 Figura 4.6 - Exemplo de Diagrama de Transição de Estados .......................................................................................55 Figura 4.7 - Exemplo de Diagrama de Corpo de Método .............................................................................................57 Figura 6.1 – Esquema do Ambiente SEA com inserção da Ferramenta de Apoio ao uso de frameworks[SEA00]. .....85 Figura 6.2 - esquema da ferramenta de apoio ao uso de frameworks. ..........................................................................86 Figura 6.3 - modelo de qualidade de framework multi-metrics [ERN 96]....................................................................89 Figura 6.4 – Diagrama de casos de uso da ferramenta..................................................................................................92 Figura 6.5 – Diagrama de atividades da ferramenta. ....................................................................................................93 Figura 6.6 – Diagrama de Classe com herança de Element ..........................................................................................96 Figura 6.7 - Diagrama de classe (Eapplication agrega Eclass) .....................................................................................96 Figura 6.8- Diagrama de Classe (Eclass agrega Emethod e Eattribute)........................................................................97 Figura 6.9 - Diagrama de Classe (agregações de Emethod) .........................................................................................98 Figura 6.10 – Diagrama de Classe (Eframework agrega Eclass) ..................................................................................98 Figura 6.11 – Diagrama de Classe (Econnect)..............................................................................................................99 Figura 6.12 – Diagrama de Classe (FrameworkDataExtractTool)..............................................................................100 Figura 6.13 – Diagrama de Seqüência (SaveApplication) ..........................................................................................101 Figura 6.14 – Diagrama de Classes – Detalhe da ferramenta de análise de uso de frameworks .................................102 Figura 6.15 – Diagrama de classes (UseAnalyserTool)..............................................................................................103 Figura 6.16 – Diagrama de classes (ToolInitialize/FrameworkAnalyserUseTool) .....................................................104 Figura 6.17 – Diagrama de Seqüência (FrameworkAnalyserUseTool/Initialize) .......................................................105 Figura 6.18 – Diagrama de Seqüência (textAnalysis).................................................................................................105 Figura 6.19 – Diagrama de Seqüência (graphAnalysis)..............................................................................................106 Figura 6.20 – Diagrama de Seqüência (procedeGraphAnalysis) ................................................................................107 Figura 6.21 – Visão hierárquica dos dados de uso de framework...............................................................................110 Figura 6.22 – Visão de tabela/gráfico dos dados de uso de framework ......................................................................111 Figura 7.1 – Interface dos jogos desenvolvidos sob o framework FraG. ....................................................................112 Figura 7.2 – Diagrama de casos de uso do framework de jogos .................................................................................113 Figura 7.3 – Diagrama de Atividades do framework de jogos....................................................................................114 Figura 7.4 - Diagrama de Classes (detalhe da classe ClickController) .......................................................................115 Figura 7.5 – Diagrama de classes – detalhe da classe GameInterface ........................................................................116 Figura 7.6 – Diagrama de classes – detalhe da classe View .......................................................................................116 Figura 7.7 - Diagrama de Classes (subclasses de Model)...........................................................................................117 Figura 7.8 – Detalhe das classe Player e Piece ...........................................................................................................118 Figura 7.9 – Diagrama de classe (detalhe da classe Dice) ..........................................................................................118 Figura 7.10 – Diagrama de classe (detalhe da classe Dice) ........................................................................................119 Figura 7.11- Diagrama de Seqüência (iniciar do jogo) ...............................................................................................120 Figura 7.12 - Diagrama de Seqüência (lance do jogo)................................................................................................121 Figura 7.13- Diagrama de Seqüência (ação sobre uma posição do tabuleiro).............................................................121 Figura 7.14- Diagrama de Seqüência (ação sobre um dado do jogo)..........................................................................122 Figura 7.15 – Classes não referenciadas pelos jogos (visão hierárquica) ...................................................................127.

(9) ix. LISTA DE TABELAS Tabela 6.1 – Comparativo dos métodos/ferramentas de apoio ao desenvolvimento e uso de frameworks……............91.

(10) x. LISTA DE QUADROS Quadro 6.1 – Dados no formato de relatório .............................................................................................................109 Quadro 6.2 – Dados no formato de registro de exportação.........................................................................................109.

(11) xi. LISTA DE GRÁFICOS Gráfico 7.1- Classes exclusivas da aplicação .............................................................................................................123 Gráfico 7.2 - Classes diretamente referenciadas.........................................................................................................124 Gráfico 7.3 - Classes indiretamente referenciadas......................................................................................................125 Gráfico 7.4 - Classes indiretamente referenciadas......................................................................................................125 Gráfico 7.5 - Total de classes da aplicação.................................................................................................................126 Gráfico 7.6 - Total de classes do framework não referenciadas .................................................................................126 Gráfico 7.7 - Percentual de reuso de classes...............................................................................................................127 Gráfico 7.8 - Percentual de desenvolvimento de classes ............................................................................................128 Gráfico 7.9 - Métodos exclusivos da aplicação ..........................................................................................................129 Gráfico 7.10 - Métodos diretamente referenciados.....................................................................................................129 Gráfico 7.11 - Métodos indiretamente referenciados..................................................................................................130 Gráfico 7.12 - Total de métodos referenciados...........................................................................................................130 Gráfico 7.13 - Total de métodos da aplicação ............................................................................................................131 Gráfico 7.14 - Total de métodos não referenciados ....................................................................................................131 Gráfico 7.15 - Percentual de reuso de métodos ..........................................................................................................132 Gráfico 7.16 - Percentual de desenvolvimento de métodos ........................................................................................132 Gráfico 7.17 - Atributos exclusivos da aplicação .......................................................................................................133 Gráfico 7.18 - Atributos diretamente referenciados....................................................................................................134 Gráfico 7.19 - Atributos indiretamente referenciados.................................................................................................134 Gráfico 7.20 - Total de atributos referenciados ..........................................................................................................135 Gráfico 7.21 - Total de atributos da aplicação ............................................................................................................135 Gráfico 7.22 - Total de atributos da aplicação ............................................................................................................136 Gráfico 7.23 - Percentual de reuso de atributos ..........................................................................................................136 Gráfico 7.24 - Percentual de desenvolvimento de atributos........................................................................................137 Gráfico 7.25 - Comandos exclusivos da aplicação .....................................................................................................138 Gráfico 7.26 - Comandos referenciados de forma direta ............................................................................................138 Gráfico 7.27 - Comandos referenciados de forma indireta .........................................................................................139 Gráfico 7.28 - Total de comandos referenciados ........................................................................................................139 Gráfico 7.29 - Total de comandos da aplicação..........................................................................................................140 Gráfico 7.30 - Total de comandos não referenciados .................................................................................................140 Gráfico 7.31 - Percentual de reuso de comandos........................................................................................................141 Gráfico 7.32 - Percentual de desenvolvimento de comandos .....................................................................................141 Gráfico 7.33 - Classes exclusivas da aplicação...........................................................................................................142 Gráfico 7.34 - Classes especializadas pela aplicação..................................................................................................142 Gráfico 7.35 - Número de classes novas.....................................................................................................................143 Gráfico 7.36 - Percentual de classes especializadas....................................................................................................143 Gráfico 7.37 - Percentual de classes especializadas....................................................................................................144 Gráfico 7.38 - Métodos exclusivos da aplicação ........................................................................................................144 Gráfico 7.39 - Métodos sobrescritos na aplicação ......................................................................................................145 Gráfico 7.40 - Métodos novos definidos na aplicação................................................................................................145 Gráfico 7.41 - Percentual de sobrescrita de métodos..................................................................................................146 Gráfico 7.42 - Percentual de novos de métodos..........................................................................................................146 Gráfico 7.43 - Comandos exclusivos da aplicação .....................................................................................................147 Gráfico 7.44 - Comandos sobrescritos na aplicação ...................................................................................................147 Gráfico 7.45 - Comandos novos da aplicação ............................................................................................................148 Gráfico 7.46 - Percentual de sobrescrita de comandos ...............................................................................................148 Gráfico 7.47 - Percentual de novos comandos............................................................................................................149 Gráfico 7.48 - Número de classes redefinidas - previsto ............................................................................................150 Gráfico 7.49 - Número de classes redefinidas – não previsto.....................................................................................150 Gráfico 7.50 - Total de classes redefinidas.................................................................................................................151 Gráfico 7.51 - Percentual de classes redefinidas - previsto.........................................................................................151 Gráfico 7.52 - Percentual de classes redefinidas – não previsto .................................................................................152 Gráfico 7.53 - Número de métodos template sobrescritos ..........................................................................................153 Gráfico 7.54 - Número de métodos abstratos sobrescritos .........................................................................................154 Gráfico 7.55 - Número de métodos abstratos sobrescritos .........................................................................................154.

(12) xii. Gráfico 7.56 - Número de métodos abstratos sobrescritos .........................................................................................155 Gráfico 7.57 - Percentual de métodos template sobrescritos ......................................................................................155 Gráfico 7.58- Percentual de métodos abstratos sobrescritos.......................................................................................156 Gráfico 7.59- Percentual de métodos regulares sobrescritos ......................................................................................156 Gráfico 7.60- Número de métodos template hook sobrescritos ..................................................................................157 Gráfico 7.61 - Número de métodos abstratos hook sobrescritos.................................................................................157 Gráfico 7.62 - Número de métodos regulares hook sobrescritos ................................................................................158 Gráfico 7.63 - Percentual de métodos template hook sobrescritos .............................................................................158 Gráfico 7.64 - Percentual de métodos abstratos hook sobrescritos.............................................................................159 Gráfico 7.65 - Percentual de métodos regulares hook sobrescritos ............................................................................159.

(13) xiii. RESUMO Este trabalho propõe um conjunto de medidas a serem extraídas a partir da especificação de frameworks orientados a objetos e de especificações de aplicações desenvolvidas sob esses frameworks. Os dados obtidos possibilitam a comparação estatística de características de uma dada aplicação com outras aplicações especificadas sob o mesmo framework, subsidiando o desenvolvedor da aplicação na avaliação do seu trabalho de desenvolvimento, comparando-o com outros desenvolvimentos existentes. Por outro lado, os dados referentes à especificação das aplicações poderão ser úteis para o desenvolvedor do framework, como subsídio à análise da aderência do framework ao domínio tratado. Este trabalho propõe também a automação da extração dessas medidas, através de uma ferramenta de apoio ao uso de frameworks. Através das especificações de frameworks e de artefatos de software gerados sob frameworks, a ferramenta possibilita a extração e o armazenamento de dados referentes ao reuso/desenvolvimento de artefatos nas aplicações.. Palavras-chaves: Orientação a Objetos, Frameworks orientados a objetos, reuso de projeto, apoio ao uso de framework, ferramenta de apoio ao uso de frameworks..

(14) xiv. ABSTRACT This work proposes a set of metric to provide a statistical comparison of extracted characteristics from an object-oriented frameworks specification and specifications from applications developed under the frameworks. The information extracted from metric serves as reference to application developer evaluates his work when compared with other existent applications. Furthermore, the information coming from applications specification are useful for adherence analysis of the framework in a given domain. This work also presents a tool allows the automation of metrics extraction and the storage of data concerned with reuse-development of artifacts through frameworks in applications.. Keywords: Object-Oriented, Object-Oriented framework, Design reuse, Support of utilization framework, Support tool utilization of framework.

(15) 15. 1. INTRODUÇÃO. A Engenharia de software visa o desenvolvimento de metodologias e técnicas que buscam melhorar a qualidade dos artefatos de software1, permitindo ainda diminuir o tempo e o esforço necessário ao desenvolvimento. Com vista a essa finalidade, o reuso de artefatos de software é um dos alvos de pesquisa. Embora a reutilização não seja uma característica particular da orientação a objetos, se consolida como um dos fatores que impulsionam e motivam o desenvolvimento de software orientado a objetos [COL96]. Neste trabalho são descritos os principais mecanismos de suporte à reutilização, originados do paradigma de orientação a objetos, tais como classes abstratas, padrões de projeto e frameworks. Se, por um lado, o desenvolvimento orientado a objetos mostrase favorável à produção de componentes de software reutilizáveis, através dos mecanismos naturais da orientação a objetos como a herança e o polimorfismo, por outro, essa tecnologia é carente em mecanismos de suporte ao desenvolvimento e uso dos artefatos reutilizáveis. Desenvolver software reutilizável é mais complexo que desenvolver aplicações específicas, pois exige que os desenvolvedores conheçam profundamente o domínio para o qual o mesmo será desenvolvido. Usar artefatos reutilizáveis está relacionado à possibilidade de ganho de produtividade e qualidade dos softwares produzidos a partir desses artefatos, porém, seu uso deve ser assistido por técnicas e ferramentas que de fato auxiliem o usuário a atingir tais objetivos. Frameworks orientados a objetos representam uma categoria de artefatos de software potencialmente capazes de promover reuso de alta granularidade [JOH88]. Trata-se de uma estrutura de classes interligadas, correspondente a uma implementação inacabada, para um conjunto de aplicações de um determinado domínio – ou para um. 1. Artefato de software, neste trabalho, não diz respeito somente a código, mas também pode ser. usado para referenciar produtos da fase de análise e projeto, ou ainda para se referir a uma aplicação ou a um framework..

(16) 16. subsistema de aplicação – destinada a ser estendida para o desenvolvimento de aplicações específicas. Dois obstáculos associados à abordagem de desenvolvimento de software a partir de frameworks são a complexidade associada ao desenvolvimento de frameworks e a complexidade associada ao uso de frameworks. O desenvolvimento se torna complexo, pois o projetista necessita construir uma estrutura de classes capaz de generalizar um domínio e, ao mesmo tempo, permitir a adaptação às especificidades de cada aplicação. O uso do framework é complexo, pois, na maioria das vezes, o usuário precisa entender a estrutura interna do framework antes de usá-lo no desenvolvimento de aplicações. Nesse caso, o usuário é dependente de uma documentação capaz de passar o conhecimento inserido pelo desenvolvedor do framework. Outro instrumento que pode ajudar o desenvolvedor de aplicações sob frameworks é a possibilidade de, durante o processo de desenvolvimento, serem fornecidos parâmetros comparativos dos dados de desenvolvimento de sua aplicação com outras aplicações já desenvolvidas sob o mesmo framework. Esses dados podem fornecer subsídios para a identificação de possíveis anomalias no desenvolvimento da aplicação, ou ainda, diagnosticar deficiências que o framework possa apresentar, subsidiando também o desenvolvedor do framework. Nesse sentido, este trabalho propõe um conjunto de medidas a serem extraídas a partir de especificações de framework orientados a objetos e das especificações das aplicações desenvolvidas sob o framework. Esses dados extraídos possibilitam a comparação de uma dada aplicação com outras aplicações especificadas sob o mesmo framework, subsidiando o desenvolvedor da aplicação para a avaliação de seu trabalho de desenvolvimento, através da comparação com outros desenvolvimentos existentes. Por outro lado, os dados referentes à especificação das aplicações poderão ser utilizados pelo desenvolvedor do framework, como subsídio à análise da aderência do framework ao domínio tratado. Também é apresentado um protótipo de uma ferramenta que quantifica aspectos de reuso de um framework, inserido no ambiente SEA original [SIL 2000]. Através da análise de especificações de frameworks e de artefatos de software gerados sob frameworks, especificadas no ambiente, essa ferramenta possibilita a extração e o armazenamento de dados referentes a reuso em aplicações especificadas sob um framework..

(17) 17. O presente trabalho está organizado em oito capítulos e um anexo, cujos conteúdos estão descritos a seguir. O capítulo 2 descreve características do paradigma de orientação a objetos referentes ao reuso de artefatos de software, mostrando os principais mecanismos da orientação a objetos que proporcionam reutilização. No capítulo 3 são tratados aspectos conceituais, processo de desenvolvimento, documentação e uso de frameworks orientados a objetos. São descritos os passos a serem seguidos no desenvolvimento de frameworks, as abordagens de documentação e obtenção de informações de um framework e, por último, o uso de frameworks. No capítulo 4 é feita uma descrição do ambiente SEA, mostrando os aspectos mais significativos ao contexto deste trabalho. O capítulo 5 descreve o conjunto de medidas que visam indicar características relacionadas ao reuso de frameworks orientados a objetos, através da análise de aplicações desenvolvidas sob esses frameworks. No capítulo 6 é apresentada a ferramenta de apoio ao uso de frameworks. São descritos os modelos, a arquitetura da ferramenta e seus principais resultados. No capítulo 7 é apresentado um estudo de caso sobre um framework e quatro aplicações desenvolvidas sob esse framework. Analisa a especificação desenvolvida através de engenharia reversa do framework FraG (framework para jogos de tabuleiro) e quatro jogos desenvolvidos sob esse framework (Jogo da Corrida, Jogo da Corrida Plus, Jogo da Velha e Jogo Reversi) [SIL97]. No capítulo 8 são apresentadas as conclusões e considerações finais deste trabalho. O anexo apresenta parte da especificação do framework de jogos e parte das especificações dos jogos desenvolvidos sob esse framework..

(18) 18. 2. 2.1. PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Introdução A produção de software exige padrões de documentação, formalismo nas. representações dos requisitos e soluções propostas, e uma seqüência lógica de desenvolvimento, que mostre os passos que devem ser percorridos e quais produtos serão produzidos em cada um dos passos [COL96]. Para que o processo de desenvolvimento possa ser gerenciado e conduzido, é necessário o uso de uma metodologia. Uma boa metodologia de desenvolvimento de software deve oferecer uma sistemática para as fases de análise, projeto e implementação [COL96]. Vale ressaltar que um dos maiores problemas detectados no processo de desenvolvimento é a pressa em se chegar até a fase de implementação, haja vista que nessa fase, teoricamente tem-se o produto, o software. O reflexo disso é que as fases de análise e projeto são desenvolvidas de forma superficial, aumentando os riscos de inserção de erros de especificação e de projeto de software. Métodos de desenvolvimento mais sistematizados consomem mais tempo durante as fases de análise e projeto, possibilitando uma maior compreensão dos requisitos, evitando a omissão ou ambigüidade de funcionalidades importantes para o software. Quanto mais explorado o assunto nessas fases, melhores serão os conceitos inerentes ao assunto, tornando o produto final mais aderente ao resultado esperado. O desenvolvimento de software pode se tornar complexo, devido à própria complexidade da realidade que será automatizada [COL96]. A saída para podermos lidar com essa complexidade é decompor o problema em partes menores, onde cada parte é menos complexa que o todo estudado. A decomposição do projeto facilita o trabalho em equipe, visto que além de decompor o projeto, o método deve fornece notações (padrões de documentos) que facilitam o entendimento por todos os integrantes da equipe..

(19) 19. 2.2. Qualidade de Software O final da década de 60 foi conhecida como o período da crise do software,. devido aos problemas envolvendo a ineficiência das estimativas de custos e prazos de desenvolvimento e manutenção de software. Outro aspecto motivador foi à insatisfação dos clientes com o resultado final, ou seja, com o produto obtido. Um dos fatores mais fortes para a crise do software foi o fato que a grande maioria do desenvolvimento acontecia sem o apoio de técnicas e metodologias de desenvolvimento. A solução foi adotar um processo de desenvolvimento apoiado por uma abordagem metodológica que estabelecesse passos e critérios bem definidos para desenvolvimento, manutenção, gerenciamento do processo de desenvolvimento, estimativas de custos e prazos [SIL01], garantindo assim, que todo processo de desenvolvimento de software seja produzido visando qualidade. Segundo Silva [SIL00], a qualidade do processo de desenvolvimento de software pode ser dividida em dois aspectos. O aspecto tecnológico se refere às técnicas de modelagem, procedimentos de análise e projeto do software. O aspecto gerencial se refere à coordenação dos trabalhos, à avaliação e controle dos prazos. Para atender a necessidade de acompanhamento e avaliação do processo de desenvolvimento de software foram desenvolvidas normas que estabelecem padrões de qualidade. Como exemplos podem ser citados: ISSO/IEC 12207 (Software Life Cycle Process - qualidade do processo de desenvolvimento de software)[WEB 99], NBR ISO 9001 (Sistemas de qualidade - Modelo para garantia de qualidade em Projeto, Desenvolvimento, Instalação e Assistência Técnica)[HUT 94]. Segundo Pressman [PRE95], na maioria dos empreendimentos técnicos, as medições e as métricas ajudam a entender o processo técnico usado para se desenvolver produto, como também o próprio produto. O domínio das métricas é classificado de diferentes formas por diversos autores. Segundo Pressman [PRE95] as métricas de software podem ser divididas nas seguintes categorias: x. Métricas de produtividade – medidas do resultado de desenvolvimento de software como uma função do esforço aplicado..

(20) 20. x. Métricas da qualidade - indicam o quanto o software está em conformidade às exigências implícitas e explícitas do cliente.. x. Métricas Técnicas – essas métricas tratam especificamente de características de software (complexidade lógica e grau de modularidade) e não o processo utilizado para desenvolver o software.. Fazer medidas durante o processo de desenvolvimento de software é importante, porque é possível avaliar o que está sendo produzido e identificar melhorias nas técnicas de projetos e de codificação.. 2.3. Modelo de desenvolvimento orientado a objetos A principal característica do desenvolvimento baseado em objetos é a. identificação e organização dos conceitos do domínio da aplicação. É uma das tarefas mais difíceis, devido à complexidade do problema. Durante boa parte da história da tecnologia da orientação a objetos foi dado maior ênfase à implementação do que à análise e projeto. As pesquisas mostraram que o trabalho conceitual desenvolvido na fase de análise e projeto pode antecipar ou evitar possíveis problemas, que seriam mais dispendiosos se fossem encontrados na fase de implementação. O desenvolvimento baseado em objetos estimula os desenvolvedores à trabalharem com o domínio da aplicação durante um tempo maior do ciclo de desenvolvimento. Somente quando os conceitos relativos à aplicação forem localizados, organizados e entendidos é que serão considerados os detalhes de implementação. Esse modelo de desenvolvimento é conceitual e independente de linguagem de programação, até o início da fase de codificação. É uma forma de pensar e organizar os conceitos de um problema e não somente uma técnica de programação. O modelo antecessor ao orientado a objetos, modelo funcional, tem como ênfase a decomposição funcional do problema [Demarco e Yordon]. Esse modelo de desenvolvimento parece mais simples e intuitivo, porém, é frágil. Caso ocorram mudanças de requisitos, poderá provocar grandes reestruturações, pois são levantados os processos de uma parte do domínio. Em contrapartida, o modelo orientado a objetos.

(21) 21. mostra-se mais flexível a inovações e mais robusto a mudanças, visto que a maior preocupação é mapear os conceitos da realidade estudada, diminuindo o risco de mudanças conceituais.. 2.3.1 Características do modelo orientado a objetos As características apresentadas nesse tópico não são, na sua totalidade, particulares da orientação a objetos, porém, formam os preceitos desse modelo de desenvolvimento. 2.3.1.1 Abstração Consiste em dar maior atenção aos aspectos essenciais de uma realidade analisada. No desenvolvimento de software significa fazer a análise e levantamento dos conceitos que compõem o domínio da aplicação. O que é cada um deles e o que faz. Somente na última etapa é que será decidido como serão implementados. A abstração permite que uma dada realidade possa ser observada em níveis de complexidade e detalhes diferentes, em momentos distintos. O uso da abstração durante a análise proporciona a manipulação apenas dos conceitos do domínio da aplicação, evitando preocupações com a fase de projeto e implementação, antes que o problema seja de fato entendido. Permite também que os mesmos modelos desenvolvidos na fase de análise sejam usados na fase de projeto, sendo somente aprofundado o nível de detalhes relativos à implementação. 2.3.1.2 Encapsulamento Diz respeito à ocultação de informação. No modelo orientado a objetos, visa estabelecer quais elementos do conceito serão restritos a ele, e os elementos que serão visíveis a outros conceitos da aplicação. Na programação orientada a objetos, o encapsulamento faz parte de seus princípios, visto que, um objeto é composto por dados e operações. Essa capacidade torna esse modelo de desenvolvimento extremamente poderoso, uma vez que possibilita o isolamento de componentes de software. Com isso é possível produzir componentes de software com capacidade de ser usado em diversas.

(22) 22. situações, sem provocar mudanças no contexto que está sendo inserido. Outra característica do encapsulamento é a facilidade de manutenção de componentes de software, sob dois aspectos: x O primeiro diz respeito ao entendimento do componente de software. Como o componente possui os dados e todo o código que os manipulam, assim é mais fácil compreendê-lo. x O segundo diz respeito à propagação de mudanças. Quanto maior o encapsulamento, menor será o impacto provocado pelas mudanças. 2.3.1.3 Polimorfismo É um instrumento extremamente útil no desenvolvimento de componentes de software reusáveis. Com esse mecanismo é possível tratar instâncias de objetos de diferentes classes sem considerar a classe de cada objeto. Isso é possível, desde que os objetos entendam um conjunto comum de mensagens. Assim, o polimorfismo reduz o número de identificadores de mensagens, pois são implementadas operações em diferentes classes com a mesma assinatura. Também diminui o impacto provocado pelas adequações do software, visto que é possível alterar as operações de um objeto mantendo seu conjunto de mensagens, minimizando o tempo, custo e risco de inserções de erros nas adequações. Por outro lado, o código que possui um alto grau de mensagens iguais, decididas em tempo de execução, dificulta seu entendimento, sendo necessária a avaliação das instâncias de objetos para conhecer a mensagem invocada. 2.3.1.4 Herança Constitui uma das características mais marcantes do modelo orientado a objetos. Esse mecanismo permite que uma nova classe seja produzida a partir de outra classe, chamada superclasse. Isso evita a necessidade de reescrever aquilo que já foi previsto. Essa técnica é chamada de desenvolvimento por diferença, visto que é desenvolvido ou redefinido aquilo que é diferente da superclasse. O maior benefício é que a superclasse permanece inalterada, não interferindo naquilo que foi desenvolvido anteriormente..

(23) 23. Caso a herança seja usada como mecanismo de especialização/refinamento de conceitos, irá produzir uma certa classificação das classes de um sistema em nível conceitual. Isso será verdade se a herança não for usada somente com o objetivo de herança de código mas também como especialização de um conceito genérico em algo mais específico. A. herança. apóia. o. desenvolvimento. de. polimorfismo. através. do. desenvolvimento de mensagens/protocolos padrões. Quando é produzida uma classe e nela são especificadas somente as assinaturas dos métodos (classes abstratas), forçará suas subclasses a implementarem esses métodos, definindo um conjunto comum de operações para um grupo de classes relacionadas por herança. 2.3.1.5 Reutilização É um dos pilares do desenvolvimento orientado a objetos, introduzido primeiramente pelas linguagens de programação orientadas a objetos, onde o objetivo é o reaproveitamento de estruturas de código e dados, ditas superclasses, que são usadas para a produção de novas estruturas, as subclasses. Com a evolução da tecnologia, buscou-se a reutilização não somente da codificação do programa, mas também a reutilização das estruturas desenvolvidas durante a especificação do projeto, ou seja, reutilização dos produtos desenvolvidos nas fases de análise e projeto de software. A reutilização pode ser dividida em dois aspectos: do ponto de vista tecnológico ou do ponto de vista do gerenciamento. 2.3.1.6 Ponto de vista do gerenciamento Trata das questões relacionadas com a gestão de artefatos de software reutilizáveis, tão quanto é importante o projeto e implementação, é a sua gestão. Tanto o lado produtor, quanto o lado consumidor dos artefatos reutilizáveis devem estar em perfeito sincronismo, evitando a duplicação, manutenções dispensáveis e a produção de estruturas verdadeiramente reutilizáveis. Esse assunto não será explorado neste trabalho, e sim, dar-se-á ênfase ao aspecto tecnológico..

(24) 24. 2.3.1.7 Ponto de vista tecnológico No modelo funcional de desenvolvimento de software, a reutilização de código foi uma forte linha de pesquisa, tratada nos aspectos abaixo relacionados: x Parametrização de programas, possibilitando sua utilização em diversas situações, através da variação de suas entradas de dados. x Modularização de partes do programa, diminuindo a redundância de código e aumentando a reutilização. x Desenvolvimento de bibliotecas de rotinas reutilizáveis, sendo possível sua utilização em diferentes sistemas. Muitos esforços de pesquisa foram desenvolvidos nesses aspectos no modelo funcional, porém, o mesmo não aconteceu no sentido de reaproveitamento dos produtos produzidos nas fases de análise de requisitos, projeto, plano de testes e documentação [COL96]. Por outro lado, o modelo orientado a objetos oferece recursos de reutilização desde a fase de análise de requisitos até a fase de implementação. Nesse modelo temos bibliotecas de código orientado a objetos, que permitem a reutilização e também sua extensão através do mecanismo de herança. Além das bibliotecas orientadas a objetos, esse modelo proporciona o desenvolvimento de modelos de análise e projetos orientados a objetos reutilizáveis para um determinado domínio de problema. São denominados de frameworks orientados a objetos ou arquitetura de domínio.. 2.3.2 Mecanismos de suporte a reutilização No modelo orientado a objetos o foco principal são as classes, que retratam o mundo estudado, representando a parte mais estática do domínio, visto que essa representação só muda se o domínio do problema mudar. O resultado disso é a produção de softwares mais robustos à mudanças de requisitos, sendo a reutilização de tais artefatos mais prováveis que no caso de unidades funcionais. Esse mecanismo é fundamentado em dois tipos de reuso: o primeiro é a composição, que é o reuso de classes contidas em uma biblioteca de classes prontas para.

(25) 25. o uso e nessa modalidade a aplicação é composta pelas classes reutilizadas. O segundo tipo é a herança, fundamentado na extensão de funcionalidades já existentes nas classes e que são estendidas e especializadas, conforme a necessidade particular da aplicação em desenvolvimento. A herança caracteriza-se como um dos principais mecanismos para a produção de estruturas reutilizáveis, no modelo orientado a objetos. Proporciona o desenvolvimento de estruturas hierárquicas, que implementam refinamentos de especificação à medida que percorremos para baixo o modelo desenvolvido. Permite que o desenvolvedor implemente uma hierarquia até determinado nível de abstração, que satisfaça suas necessidades, e que outro desenvolvedor utilize essa estrutura como ponto de partida e continue refinando até satisfazer o nível de especialização necessário ao seu desenvolvimento2. O encapsulamento proporciona a facilidade de uso das classes, visto que o usuário de uma classe3 não tem necessidade de conhecer a complexidade da implementação, e sim, o mecanismo de interface da classe. Outro aspecto do encapsulamento é a garantia que alterações realizadas na implementação dos métodos da classe podem ser totalmente absorvidos pela própria classe, não causando reflexos na forma de uso da aplicação. Outro mecanismo que estimula a reutilização é o polimorfismo, no sentido que permite que a mesma mensagem passada a objetos de um conjunto de classes relacionadas através de herança, produza comportamentos diferentes e que novas classes inseridas nesse contexto não altere a forma de uso dessas classes, evitando a alteração dos trechos de código que usam tal estrutura.. 2. Um bom exemplo disso são as ferramentas de desenvolvimento visual, que permitem que o. desenvolvedor amplie a estrutura das classes da ferramenta, especializando-as até satisfazer suas necessidades.. 3. Nesse caso de classes concretas e não artefatos reutilizáveis, como classes abstratas ou. frameworks, serão discutidos adiante..

(26) 26. 2.3.3 Tipos de Artefatos de Software Reutilizáveis Nesse tópico serão discutidos os artefatos de software que podem ser desenvolvidos para proporcionar a reutilização. Serão tratados os artefatos: classe concreta, classe abstrata, framework, padrões de projeto e componentes. Esses assuntos darão sustentação e embasamento ao objetivo do capítulo seguinte, que trata especificamente do artefato de frameworks orientados a objetos. Segundo Lajoie, existem vários níveis de reutilização dentro de um framework [LAJ94] 4, os quais serão descritos a seguir. 2.3.3.1 Classe concreta Define uma estrutura de dados e métodos construídos para satisfazer uma necessidade específica, contendo todos os dados e comportamentos necessários para seu uso. É comum a construção de bibliotecas de classes concretas, caracterizando-se como um repositório de artefatos de software pronto para o uso. Nessa categoria o usuário de tais recursos não precisa saber a complexidade interna da classe, e sim, conhecer sua interface5. 2.3.3.2 Classe abstrata É um projeto que especifica uma classe e a árvore de subclasses que poderá ser produzida a partir dela. Essas classes especificam o comportamento, mas não definem a implementação desses métodos, ficando a cargo das subclasses fazer isso. Vale ressaltar que não é necessário que todos os métodos sejam abstratos6. Nessas classes é possível. 4. Reutilização refere-se não somente a código, mas a todos produtos gerados no processo de. desenvolvimento. 5. Interface é o conjunto de todos os métodos (operações e seus parâmetros) que podem ser. invocados por outros objetos. 6. Métodos abstratos são aqueles que não possuem implementação na classe que o definem..

(27) 27. ter alguns métodos concretos7, que são considerados básicos a todas as classes descendentes. O uso de classes abstratas é justificado nas situações em que, dado um conjunto de classes, os comportamentos são semelhantes, diferenciados somente pela implementação particular de cada classe descendente. O usuário de classes abstratas deverá conhecer sua estrutura interna, visto que para estender ou sobrepor as partes reutilizáveis deverá conhecer a complexidade interna de tal estrutura. Dessa forma, as classes abstratas são estruturas flexíveis, porém, exigindo maior preparo e responsabilidade de seus usuários. 2.3.3.3 Padrões de Projeto – Design Patterns Como já foi tratado anteriormente, o desenvolvimento de software reutilizável é mais complexo que o desenvolvimento de aplicações específicas, sendo preciso definir uma estrutura capaz de satisfazer uma determinada situação, porém flexível. Neste contexto foram propostos os padrões, que segundo Chistopher Alexander cada padrão descreve um problema no nosso ambiente e o núcleo de sua solução, de tal forma que você possa usar esta solução mais de um milhão de vezes, sem nunca fazê-lo da mesma maneira [GAM00]. Padrões de projetos são estruturas de classes usadas e testadas na solução de determinada situação e que podem ser usadas novamente, toda vez que tal situação ocorrer. Os padrões descritos por Alexander são aplicados à construção civil, porém, sua fala pode ser aplicada a projetos de software orientados a objetos. Gamma, Helm, Johnson e Vlissides desenvolveram um catálogo contendo vinte e três padrões de uso geral, extraídos da experiência de cada um em localizar estruturas comuns nas especificações de aplicações orientadas a objetos [GAM94]. No ano seguinte Pree, propôs uma extensão ao catálogo com os meta-padrões, que são estruturas que documentam os métodos template8 e hook nas classes, objetivando a flexibilidade da implementação.. 7. Métodos concretos possuem implementação na própria classe que o definem..

(28) 28. Os padrões de projeto são estruturas de classe que implementam a solução de uso geral para um determinado tipo de problema. Como exemplo temos o Observer, que aplica um conjunto de classes na situação em que um objeto (observador) deve ficar atento a uma situação, e quando essa situação acorrer deve comunicar o ocorrido aos outros objetos (sujeitos). Assim sendo, nessa situação de ocorrência, para qualquer projeto, esse padrão pode ser usado. Os meta-padrões não são voltados a solucionar problemas específicos, mas sim a definição de estruturas flexíveis. Os padrões descrevem a estrutura de classe, métodos e atributos, já os meta-padrões apenas documentam os métodos template e hook.. 2.3.4. Dificuldades do modelo orientado a objetos Este modelo também sofre com a tentativa de resolver o desenvolvimento de um. aplicativo sempre através da programação, deixando de gastar tempo nas fases de análise e projeto. Outra dificuldade inerente ao modelo orientado a objetos é a identificação dos objetos no domínio9 analisado, não sendo fácil criar a cultura da orientação a objetos com equipes treinadas e habituadas a desenvolver software com o paradigma funcional. Os modelos tradicionais não oferecem mecanismos suficientes para representar as interações dinâmicas dos objetos no modelo orientado a objetos [COL96].. 2.4. Conclusão O desenvolvimento de software orientado a objetos mostra-se favorável à. produção de componentes de software reutilizáveis, através dos mecanismos naturais como a herança e o polimorfismo, porém, essa tecnologia é carente em mecanismos de suporte ao desenvolvimento e ao uso dos artefatos reutilizáveis. É necessário o. 8. Métodos templates são métodos que implementam parte ou toda a ação, invocando outros. métodos (hook). A responsabilidade da execução é dos métodos hook, já que o método templete apenas determina a ordem e quais métodos hook serão chamados. 9. Domínio aqui está relacionado ao mundo real que está sendo analisado. Mais adiante terá um. tópico específico sobre o assunto..

(29) 29. desenvolvimento de técnicas e ferramentas que dêem suporte à produção e ao uso de tais artefatos de software..

(30) 30. 3. 3.1. FRAMEWORKS ORIENTADOS A OBJETOS. Introdução Frameworks orientados a objetos representam uma categoria de artefatos de. software potencialmente capazes de promover reuso de alta granularidade [JOH88]. Trata-se de uma estrutura de classes interligadas, correspondente a uma implementação inacabada, para um conjunto de aplicações de um determinado domínio, destinada a ser estendida para o desenvolvimento de aplicações específicas. Neste capítulo são tratados os aspectos específicos do desenvolvimento e utilização de frameworks, assim como são discutidos os benefícios e dificuldades no seu uso.. 3.2. Conceito É uma estrutura de classes que se relacionam, dando origem a uma aplicação. inacabada para um conjunto de aplicações de um determinado domínio [SIL00].É um esqueleto de implementação de uma aplicação ou de um subsistema de aplicação, em um domínio particular, composto por um domínio [WIA91 apud [SIL00]]. É um conjunto de blocos de software construídos que podem ser usados, estendidos, ou customizados para atender uma solução específica [TAL94b]. Esse conjunto de classes deve ser adequado (com novas instâncias das classes propositalmente abstratas) para produzirem uma aplicação específica. Por exemplo, um framework pode ser desenvolvido para produzir editores gráficos para diferentes domínios, tais como desenho de fluxograma, desenho de projetos arquitetônicos, desenho de projetos eletrônicos, etc.. 3.3. Tipos de frameworks O framework pode ser classificado em três tipos, conforme sua estrutura interna. projetada. O primeiro, denominado de caixa-preta, é orientado a dados, constituído de.

(31) 31. classes concretas que serão reutilizadas na aplicação de forma direta, ou seja, não haverá nenhum tipo de alteração nessas classes. O segundo, denominado de caixabranca, é orientado à arquitetura, e é constituído de classes abstratas que para serem usadas na aplicação deverão ser reutilizadas na forma de herança, produzindo assim novas classes particulares à aplicação em desenvolvimento, sendo esse tipo mais flexível do que o primeiro. Existe também a possibilidade de combinar os dois tipos, produzindo um framework denominado de caixa-cinza, possuindo classes concretas e classes abstratas. Para produzir diferentes aplicações a partir de um framework, é necessário criar classes específicas para a aplicação, que correspondem às subclasses abstratas do framework. O framework define a estrutura geral da aplicação, as classes, os objetos, relacionamentos, colaborações e o fluxo de controle de aplicação, deixando para o desenvolvedor da aplicação os aspectos específicos da aplicação em desenvolvimento. Segundo Larman, um framework no caso geral, possui as seguintes características [LAR00]: x É um conjunto coeso de classes que colaboram para fornecer serviços para o núcleo invariante de um subsistema lógico. x Contém classes concretas e abstratas (especialmente), que definem as interfaces a serem seguidas, interações entre objetos que a aplicação irá participar. x Não obrigatoriamente, requer que o usuário do framework defina subclasses das classes existentes no framework, com a finalidade de estender e especificar suas funcionalidades. x Possui classes abstratas que podem conter tanto métodos abstratos como métodos concretos. x As classes definidas pelo usuário serão invocadas pelas classes prédefinidas do framework. O último item refere-se à diferença básica que existe entre o uso de bibliotecas de classes (abstratas ou concretas) e framework. Usar classes independentes significa instanciar ou redefini-las (no caso de abstratas) em uma aplicação que está sendo.

(32) 32. desenvolvida. Dessa forma, a aplicação é que irá invocar essas classes. No caso do framework, existe uma inversão dos papéis. As classes que porventura serão estendidas (personalizadas pelo usuário do framework) serão chamadas por essa estrutura, onde a aplicação é o próprio framework que está sendo moldado para a produção de uma aplicação específica. Quando um framework é usado, toda a estrutura de controle e as partes comuns às aplicações do domínio já estão definidas, e será escrito código particular à aplicação em desenvolvimento. Para isso o desenvolvedor usa nomes e convenções previamente especificadas pelo desenvolvedor do framework. O resultado é a produção de aplicações com alto índice de reutilização de código e também o desenvolvimento de aplicações com estruturas muito semelhantes, facilitando a manutenção dessas aplicações. Essa característica, por outro lado, prende o usuário do framework aos limites determinados pelo framework.. 3.4. Níveis de reuso no Framework Segundo Lajoie, o reuso de artefatos de software em um framework é dividido. em três níveis[LAJ94]: reuso em pequena escala, reuso em média escala e reuso em larga escala. Essa visão de níveis de reuso de um framework nos mostra que mesmo sendo uma estrutura de classes relacionadas em estrutura definida, um framework pode oferecer classes abstratas ou concretas para serem usadas como um artefato pertencente a uma biblioteca de classes. Nessa modalidade é classificada como pequena escala de reuso. A figura 3.1 mostra esses níveis..

(33) 33. Reuso em larga escala Framework Reuso em média escala Micro-Arquitetura Reuso em pequena escala Classes, métodos, código Figura 3.1 – Nível de reuso em um framework [LAJ94].. Quando a abstração chega ao segundo nível, o desenvolvedor tem a sua disposição classes interligadas. Trata-se de reuso de micro-arquitetura10, que corresponde à subestruturas que descrevem o comportamento das colaborações dos objetos de uma parte do framework [LAJ94]. No terceiro nível é tratada a abstração de uma estrutura que equivale a uma aplicação como um todo, com pontos pré-definidos para serem particularizados e adaptados com a finalidade de gerar uma aplicação específica.. 3.5. Desenvolvimento de Framework Quando o processo de desenvolvimento de um framework é iniciado, a maior. preocupação é para a generalidade que o framework terá em relação ao domínio tratado, como também para a característica flexibilidade (alterabilidade e extensibilidade) [SIL00]. Outra preocupação no início do desenvolvimento do framework é a definição da abrangência que o framework terá. Definir um framework com grande abrangência exige grande experiência do desenvolvedor sobre o domínio tratado, bem como o custo de desenvolvimento se torna alto. Por outro lado, o desenvolvimento de framework com abrangência menor exige menos experiência do desenvolvedor, porém, frameworks com. 10. Micro-arquitetura refere-se a padrões de projeto – design patterns.