• Nenhum resultado encontrado

O desenvolvimento de um instrumento de suporte à decisão frente ao desenvolvimento de software orientado por modelos

N/A
N/A
Protected

Academic year: 2017

Share "O desenvolvimento de um instrumento de suporte à decisão frente ao desenvolvimento de software orientado por modelos"

Copied!
88
0
0

Texto

(1)

Pró-Reitoria de Pós-Graduação e Pesquisa

Stricto Sensu em Gestão do Conhecimento e da

Tecnologia da Informação

O DESENVOLVIMENTO DE UM INSTRUMENTO DE SUPORTE

À DECISÃO FRENTE AO DESENVOLVIMENTO DE

SOFTWARE ORIENTADO POR MODELOS

Brasília - DF

2013

(2)

THÁLISSON DE OLIVEIRA LOPES

O DESENVOLVIMENTO DE UM INSTRUMENTO DE SUPORTE À DECISÃO FRENTE AO DESENVOLVIMENTO DE SOFTWARE ORIENTADO POR

MODELOS

Dissertação apresentada ao Programa de Pós-Graduação Stricto Sensu em Gestão do Conhe-cimento e da Tecnologia da Informação da Uni-versidade Católica de Brasília, como requisito parcial para obtenção do Título de Mestre em Gestão do Conhecimento e da Tecnologia da In-formação.

Orientador: Prof. Dr. Edílson Ferneda

Coorientador: Prof. Dr. Fábio Bianchi Campos

(3)

7,5cm

Ficha elaborada pela Biblioteca Pós-Graduação da UCB L864d Lopes, Thálisson de Oliveira.

O desenvolvimento de um instrumento de suporte à decisão frente ao desenvolvimento de software Orientado por Modelos. / Thálisson de Oliveira Lopes – 2013.

88 f.; il : 30 cm

Dissertação (mestrado) – Universidade Católica de Brasília, 2013. Orientação: Prof. Dr. Edílson Ferneda

Coorientação: Prof. Dr. Fábio Bianchi Campos

1. Tecnologia da informação. 2. Engenharia de software. 3. Arquitetura de computador. I. Ferneda, Edílson, orient. II. Campos, Fábio Bianchi, coorient. III. Título.

(4)
(5)
(6)

AGRADECIMENTOS

Sou grato a todos os envolvidos em meu trabalho. O aspecto teórico e a consistência metodológica do trabalho são devidos à atuação de meus orientadores de pesquisa de mestra-do, Prof. Dr. Edílson Ferneda, e à coorientação do Prof. Dr. Fábio Bianchi Campos, da Universidade Católica de Brasília, que foram bastante pacientes, para o bom andamento do trabalho desde o seu início até o seu final.

Aos amigos, que tenho a sorte e o prazer de compartilhar o ambiente de trabalho, agradeço por cooperarem nas críticas iniciais de meu instrumento de pesquisa. Agradeço tam-bém as empresas e seus respectivos colaboradores que participaram na contribuição da con-cretização da pesquisa.

Sou grato aos meus pais, Antonio Lopes Ferreira e Neide de Oliveira Soares Lopes, e ao meu irmão Thiago de Oliveira Lopes, que me incentivaram, me apoiaram e acreditaram que venceria mais esse desafio em minha vida. Agradeço por sempre estarem ao meu lado.

Sou grato especialmente à Izabel Cristina de Carvalho Lopes, minha esposa, pelo apoio incansável demonstrado de modo tão especial durante a produção desta pesquisa, com-partilhando de minhas incertezas e frustrações, e ajudando ativamente para que a pesquisa se realizasse.

(7)

“Nas grandes batalhas da vida, o primeiro passo para a vitória é o desejo de vencer.”

(8)

RESUMO

Referência: Lopes, Thálisson de Oliveira. O desenvolvimento de um instrumento de supor-te à decisão frensupor-te ao desenvolvimento de software Orientado por Modelos. 2013. 88f. Mestrado em Gestão do Conhecimento e da Tecnologia da Informação, Universidade Católica de Brasília, Brasília, 2013.

O desenvolvimento de sistemas baseado em modelos, ou Model-Driven Development (MDD)

pode ser considerado uma opção para acompanhar os constantes avanços da tecnologia e con-sequentes mudanças de requisitos e reuso de componentes. A ideia básica do MDD é a gera-ção de códigos por meio de modelos a partir da especificagera-ção de componentes de software de forma independente de sua implementação técnica. Essa abordagem interessa, em particular, aos profissionais de TI envolvidos em criação de sistemas de software, pois enfatiza o uso de modelos no ciclo de vida de desenvolvimento de software. Ao fazer do modelo o elemento central desse processo e, por meio de transformações, seja de modelos em modelos ou de mo-delos em código, torna-se possível a geração automática de código-fonte. Advoga-se que par-te da complexidade inerenpar-te ao software fica por conta das ferramentas geradoras de código. Isso se reflete positivamente na incidência de erros e, consequentemente, na produtividade, qualidade, interoperabilidade na produção e na manutenibilidade de artefatos de software. Esta pesquisa tem por objetivo evidenciar os fatores nos quais as organizações podem se apoiar para uma decisão de mudança das abordagens tradicionais de desenvolvimento de sof-tware para MDD. A diversidade de abordagens, cada uma com suas respectivas implementa-ções e inovaimplementa-ções, dificulta a decisão em uma organização sobre qual delas melhor se ajusta às suas características. Buscando contribuir neste contexto, foi criado e aplicado um questionário para evidenciar características na organização que indiquem o grau de seu alinhamento ao MDD. Esse questionário é o principal resultado da pesquisa e foi baseado em uma lista de fatores candidatos que possam expressar o alinhamento de uma organização ao desenvolvi-mento por modelos. Tal questionário resultou de uma pesquisa bibliográfica e um exercício prático do MDD e foi avaliado por profissionais de TI com envolvimento em engenharia de software. Após ajustes, o instrumento foi aplicado em três organizações, constatando-se a sua utilidade para a verificação e avaliação da aderência do MDD a elas.

(9)

ABSTRACT

The development of information systems based on Model-Driven Development (MDD) can be considered an option to keep up with the everyday advances in technology and the conse-quent changing in requirements and component reuse. The basic idea of MDD is the code generation using models from the specification of software components independently of their technical implementation. This approach is interesting, particularly, for IT professionals in-volved in the creation of software systems, since it emphasizes the use of models in the life cycle of software development. By taking the model as the core of this process and, by means of transformations of models to models or from models to code, it enables the automatic gen-eration of source code. It can be argued that the software complexity is mainly on the tools for code generation. The advantages can be observed in the reduction of errors and, consequently, in the increment of productivity, quality, interoperability in production, and maintainability of software artifacts. This research aims to highlight the organizational issues that can be consid-er to drive a decision of changing from traditional approaches for a MDD approach. The di-versity of approaches, with different implementations and innovations, complicates the deci-sion on which solution best suits the organizational characteristics. Seeking to contribute in this context, a questionnaire was created and applied to identify characteristics in the organi-zation that indicates the degree of adherence to MDD. This questionnaire is the main result of this research and was based on a list of candidate features that can express the adherence of an organization to MDD. It resulted from a literature review and a practical exercise of MDD, that was evaluated by IT professionals with involvement in software engineering. After ad-justments, the instrument was administered to three organizations with evidence of its useful-ness for the verification and evaluation of adherence of them to MDD.

(10)

LISTA DE FIGURAS

Figura 1. Modelo de casos de uso ... 26

Figura 2. Estrutura do MDA ... 27

Figura 3. Conceitos chave do MDA ... 28

Figura 4. Exemplo de definições de extração de dados para linguagem JAVA... 29

Figura 5. Exemplo de um documento XMI ... 30

Figura 6. Esquema de utilização do Acceleo ... 43

Figura 7. Exemplo de diagrama de casos de uso... 43

Figura 8. Exemplo de diagrama de classes ... 44

Figura 9. Edição visual do XMI ... 45

Figura 10. Estrutura do XMI ... 45

Figura 11. Exemplo de um template do Acceleo ... 46

(11)

LISTA DE GRÁFICOS

Gráfico 1. Quantitativo de experiência em TI na empresa B ... 55

Gráfico 2.Quantitativo de projetos de desenvolvimento de software na empresa B ... 55

Gráfico 3. Consolidação dos dados do questionário na empresa A ... 56

Gráfico 4. Consolidação dos dados do questionário na empresa B ... 57

Gráfico 5. Consolidação dos dados do questionário na empresa C ... 58

Gráfico 6. Consolidação dos dados de clareza das questões ... 58

Gráfico 7. Consolidação dos dados de objetividade das questões ... 59

Gráfico 8. Distribuição dos fatores na empresa A ... 60

Gráfico 9. Distribuição dos fatores na empresa B ... 60

Gráfico 10. Distribuição dos fatores na empresa C ... 61

Gráfico 11. Distribuição das questões relacionadas com Fator 1 da empresa A ... 62

Gráfico 12. Distribuição das questões relacionadas com Fator 1 da empresa B ... 62

Gráfico 13. Distribuição das questões relacionadas com Fator 1 da empresa C ... 63

Gráfico 14. Relação entre a sugestão de referência e as empresas A e B... 63

Gráfico 15. Relação entre a sugestão de referência e a empresa C ... 64

Gráfico 16. Quantitativo de experiência em TI na empresa A ... 85

Gráfico 17. Quantitativo de projetos de desenvolvimento de software na empresa A ... 85

Gráfico 18. Quantitativo de experiência em TI na empresa C ... 85

(12)

LISTA DE QUADROS

Quadro 1. Fatores candidatos ao alinhamento do MDD ... 42

Quadro 2. Atualização dos fatores candidatos para o alinhamento ao MDD ... 48

Quadro 3. Relação de perguntas de acordo com os fatores com justificativas ... 49

Quadro 4. Comentários dos respondentes de acordo com os questionamentos ... 52

Quadro 5. Considerações sobre os comentários dos respondentes ... 53

Quadro 6. Relação de perguntas resumidas ... 57

Quadro 7. Dados dos profissionais da empresa A ... 83

Quadro 8. Dados dos profissionais da empresa B ... 83

(13)

LISTA DE SIGLAS

CIM The Computation Independent Model EMF Eclipse Modeling Framework ES Engenharia de Software

IDE IntegratedDevelopmentEnvironment MDA Model-DrivenArchitecture

MDD Model-Driven Development MOF Meta Object Facility OCL Object Constraint Language OMG Object Management Group PHP Hypertext Preprocessor PIM Platform Independent Model PSM Platform Specific Model QVT Query/View/Transformation TI Tecnologia da Informação UML Unified Modeling Language

WSDL Web Services Description Language XMI XML Metadata Interchange

(14)

SUMÁRIO

1 INTRODUÇÃO ... 16

1.1A IMPORTÂNCIA DO SOFTWARE ... 17

1.2A EVOLUÇÃO HISTÓRICA DO SOFTWARE ... 17

1.3SOBRE A ENGENHARIA DE SOFTWARE ... 18

1.3.1 Problemas comuns no desenvolvimento de software ... 19

1.3.2 Abordagens da engenharia de software ... 20

1.3.3 Geradores de código ... 20

1.4DELIMITAÇÃO DO PROBLEMA ... 21

1.5MOTIVAÇÃO ... 21

1.6OBJETIVOS ... 23

2 REFERÊNCIAL TEÓRICO ... 25

2.1A NOÇÃO DE MODELO ... 25

2.2TEORIAS DE BASE DO MDD ... 26

2.2.1 Acerca do MDA ... 26

2.2.2 Unified Modeling Language ... 28

2.2.3 Meta Object Facility ... 29

2.2.4 XML Metadata Interchange ... 29

2.2.5 Object Constraint Language ... 30

2.2.6 Query/View/Transformation ... 31

2.3FERRAMENTAS DE DESENVOLVIMENTO ... 31

2.3.1 AndroMDA ... 31

2.3.2 Acceleo ... 32

2.3.3 Eclipse Modeling Framework ... 32

2.3.4 MoDisco ... 32

2.4ALGUMAS APLICAÇÕES DO MDD ... 33

2.5RELEVÂNCIA DOS MÉTODOS BASEADOS EM MODELOS ... 35

3 ASPECTOS METODOLÓGICOS ... 37

3.1CLASSIFICAÇÃO DA PESQUISA ... 37

3.2ETAPAS DO TRABALHO DE PESQUISA ... 37

4 REALIZAÇÃO DA PESQUISA ... 41

4.1FATORES PARA ALINHAMENTO AO MDD ... 41

4.2EXERCÍCIO PRÁTICO DO MDD ... 42

(15)

4.4PRÉ-TESTE DO QUESTIONÁRIO DE PESQUISA ... 50

4.4.1 Seleção das organizações ... 50

4.4.2 Aplicação do pré-teste do questionário ... 51

4.5ANÁLISE DO PRÉ-TESTE E AJUSTES NO QUESTIONÁRIO ... 52

4.6SELEÇÃO DOS PROFISSIONAIS DE TI DAS ORGANIZAÇÕES ... 54

4.7APLICAÇÃO DO QUESTIONÁRIO DE PESQUISA ... 56

4.8ANÁLISE DOS RESULTADOS DA APLICAÇÃO DO INSTRUMENTO DE PESQUISA .. 59

5 CONCLUSÃO E TRABALHOS FUTUROS ... 67

5.1RESULTADOS DA PESQUISA ... 67

5.2LIMITAÇÕES DA PESQUISA ... 67

5.3CONCLUSÃO ... 67

5.4OPORTUNIDADES DE PESQUISAS FUTURAS IDENTIFICADAS ... 69

REFERÊNCIAS ... 70

APÊNDICE A – Versão inicial do questionário de pesquisa ... 74

APÊNDICE B – Segunda versão do questionário de pesquisa ... 78

APÊNDICE C – Formulário de identificação de perfil dos profissionais de TI ... 82

APÊNDICE D – Dados brutos dos resultados do Apêndice C ... 83

APÊNDICE E – Quantitativos das empresas A e C com base no Apêndice C ... 85

(16)

1 INTRODUÇÃO

Desde o início da década de 1980, cresce a necessidade e importância dos sistemas de software – oferecendo oportunidades e/ou apresentando dificuldades em todo seu ciclo de vida. O projeto e a capacidade de ser “amigável ao ser humano” (human-friendly) em um

pro-duto de software diferenciam-no dos propro-dutos concorrentes projetados para os mesmos fins. Além disso, sistemas de software podem fazer a diferença em um negócio (PRESSMAN, 1995, p. 3).

Pressman (2006, p. 4) nos traz o seguinte conceito de software:

Software são (1) instruções (programas de computadores) que quando executadas fornecem as características, função e desempenho desejados; (2) estruturas de dados que permitem aos programas manipular adequadamente a informação; e (3) docu-mentos que descrevem a operação e o uso dos programas.

O termo software é comumente associado a programas de computador. Essa visão, no entanto, é restritiva. Mais do que um programa, os softwares abrangem também sua documen-tação e os dados de configuração necessários para fazer com que esses programas operem corretamente (SOMMERVILLE, 2007).

O software é um conjunto de instruções usadas para adquirir entradas, manipulá-las e produzir a saída desejada em termos de funções e de desempenho, tal como determinado pelo utilizador do software. Ele é composto também de um conjunto de documentos, tais como manuais para ajudar os usuários a compreendê-lo. Os softwares atuais são compostos de códi-go fonte, executáveis, documentos de projeto, operações e seus diversos manuais (de sistema, de instalação, de implementação, entre outros) (AGARWAL; TAYAL; GUPTA, 2010).

O software como produto de engenharia é o grande objetivo almejado. Busca-se con-seguir obter um produto confiável, eficiente e economicamente viável. Um software se carac-teriza por um conjunto de componentes abstratos – estruturas de dados e algoritmos – encap-sulados na forma de procedimentos, funções, módulos, objetos ou agentes, podendo estar in-terconectados entre si, compondo uma arquitetura que deverá ser executada em sistemas com-putacionais (TONSIG, 2008).

(17)

1.1A IMPORTÂNCIA DO SOFTWARE

No início do uso do computador, o principal desafio era desenvolver um hardware que reduzisse o custo de processamento e armazenagem de dados. Ao longo da década de 1980, avanços na microeletrônica resultaram em maior poder de computação a um custo cada vez mais baixo. O principal desafio durante a década de 1990 era melhorar a qualidade (e reduzir o custo) de soluções baseadas em computador – soluções implementadas com software.

Softwares impulsionam cada vez mais as tomadas de decisões de negócios, a investi-gação científica e a engenharia de resolução de problemas. Eles afetam quase todos os aspec-tos de nossas vidas e se difundiram em nosso comércio, nossa cultura e nossas atividades tidianas. Com o crescimento da importância de se desenvolver software de qualidade, a co-munidade de software tenta continuamente desenvolver tecnologias que tornem mais fácil, rápida e menos dispendiosa sua construção (AGARWAL; TAYAL; GUPTA, 2010).

Um software, em diversos casos, é criado para resolver problemas. Nas últimas quatro décadas, tentou-se resolver uma série de problemas, de diferentes tipos, com software, em alguns casos excepcionalmente bem sucedidos. Tradicionalmente, a indústria de software é focada no fornecimento de sistemas computacionais de alta qualidade, com fins específicos para o usuário final. Muito esforço tem sido investido em desenvolver software de maneira mais eficiente, proporcionando enormes conjuntos de componentes de software pré-fabricados. Muito esforço tem sido investido também no aumento da utilidade do software, para, assim, fornecer soluções personalizadas ao usuário (KAISLER, 2005).

1.2 A EVOLUÇÃO HISTÓRICA DO SOFTWARE

A evolução da informática veio acompanhada do aumento da complexidade no ciclo de vida dos sistemas de software (WANG et al., 2012). Devido à dinâmica dos ambientes em que tais sistemas operam, alterações, adaptações e correções são frequentes (PRESSMAN, 2006).

Arbuckle (2011) define a evolução do software como a maneira em que os artefatos de software mudam entre as versões. Uma versão não precisa representar uma versão completa, mas pode simplesmente representar o estado atual de desenvolvimento.

(18)

que as técnicas disponíveis deveriam ser mais claras, baseadas em fundamentos teóricos e em disciplinas práticas estabelecidas em ramos tradicionais da Engenharia (MENS; DEMEYER, 2008).

Tonsig (2008, p. 67-68) discorre sobre essas ideias da seguinte forma:

O desenvolvimento de software naquela época ocorria de maneira informal, sem aplicação de qualquer método, e dependia totalmente de quem o construía, caracteri-zando-se mais por ser uma “obra de arte” do que propriamente um produto de fo r-malismo técnico. Os profissionais que desenvolviam o software, por sua vez esta-vam envolvidos com a realidade da tecnologia em si e não propriamente com os problemas que deveriam ser resolvidos. Havia características do hardware que mere-ciam muita atenção nos projetos a serem desenvolvidos e, não raramente, eram res-tritivas, especialmente aquelas pertinentes ao dimensionamento de recursos (espaço a ser utilizado em disco, por exemplo), já que o hardware era o item de maior custo. À medida que tais softwares eram desenvolvidos e crescia o número de sistemas ba-seados em computadores, passou-se a verificar que os desenvolvimentos eram mar-cados por atrasos e falhas na maioria dos projetos, que resultavam em metas não atingidas, custos imprevisíveis e sistemas de difícil manutenção.

A partir da década de 1970, surgem os sistemas distribuídos, aumentando considera-velmente a complexidade dos sistemas computacionais (PRESSMAN, 1995).

1.3 SOBRE A ENGENHARIA DE SOFTWARE

Engenharia de Software (ES) é uma disciplina da engenharia que se preocupa com to-dos os aspectos da produção de software a partir to-dos estágios iniciais de especificação do sis-tema para a manutenção do sissis-tema depois que ele entrou em uso (SOMMERVILLE, 2007). Segundo Pressman (2006), o objetivo da ES é fornecer uma estrutura para a construção de software com alta qualidade.

A ES estuda metodologias e padrões de desenvolvimento de softwares. Ela tem sido uma aliada indispensável às fábricas/empresas de software. Define métodos sistemáticos para o desenvolvimento de software, buscando melhorar e amadurecer as técnicas e ferramentas utilizadas no ambiente de desenvolvimento. Busca definir atividades e técnicas a serem utili-zadas na criação do software, oferecendo modelos, padrões, arquiteturas, métodos e processos para o contexto de desenvolvimento. Planejamento e produtividade estão entre os objetivos da ES, sendo vista como sinônimo de metodologia, padrão arquitetural e qualidade.

(19)

usuário, com possibilidade de adaptação às mudanças, estão diretamente relacionados aos métodos e controles da engenharia (LOBO, 2008).

A flexibilidade dos sistemas de software é uma das principais razões pelas quais cada vez mais softwares estão sendo incorporados em sistemas grandes e complexos. Poucos sis-temas de software hoje são inovadores (sissis-temas completamente novos), e faz muito mais sentido considerar o desenvolvimento e a manutenção como um processo continuo, ao invés de processos separados. É mais lógico pensar na ES como um processo evolutivo, onde o sof-tware é continuamente alterado durante a sua vida, conforme as mudanças nos requisitos e necessidades dos clientes (SOMMERVILLE, 2007).

Inovações no campo da tecnologia surgem continuamente. Com isso, deve-se sempre criar softwares portáveis, que comuniquem com outras tecnologias. Hoje, esta é uma caracte-rística essencial no desenvolvimento de software, visto que todo programa está ligado a outras tecnologias de maneira dinâmica. O dinamismo da alta tecnologia está no fato de que muitas pessoas estão trabalhando na sua evolução, por isso, novas ferramentas estarão sendo criadas a cada dia. É importante que um software seja desenvolvido em uma plataforma que nos per-mita utilizar estas novas ferramentas disponíveis no mercado. Utilização de modelos de sof-twares que nos permite unir tecnologias, facilitando muito no desenvolvimento e no futuro do software (LOBO, 2008).

1.3.1 Problemas comuns no desenvolvimento de software

Independentemente da atuação gerencial em projetos de software ou do planejamento estabe-lecido, existem alguns aspectos de desenvolvimento que podem comprometer a qualidade do software produzido. Para Tonsig (2008), a rápida evolução tecnológica pode suscitar a revisão de certas decisões tomadas na fase de planejamento. Segundo esse autor, a integração de sof-twares não foi considerada por várias organizações. Sabe-se que isso gera retrabalho, o que leva à possibilidade de inconsistência de dados na organização, além de erros de transcrição.

Os problemas oriundos das constantes inovações em relação a ferramentas de desen-volvimento estão relacionados principalmente ao fato delas ainda não estarem consolidadas. Isso faz com que as expectativas sobre novas tecnologias, tanto dos usuários como dos desen-volvedores, sejam frustradas (TONSIG, 2008).

(20)

1.3.2 Abordagens da engenharia de software

A complexidade cada vez maior dos sistemas baseados em computador exigem conhe-cimentos em uma série de disciplinas, como projeto de sistemas de software, design,

arquite-tura, integração de métodos formais, engenharia de integração, levantamento de requisitos e análise, processos de ciclo de vida, processos de reengenharia, reuso e técnicas de verificação. Todos estes campos têm de ser geridos por meio de métodos de ES que permitam aos enge-nheiros de projeto trabalhar dentro de um ambiente de colaboração e de acordo com roteiros bem definidos (PERSEIL, 2011).

Para padronizar a maneira como o software é construído, têm-se diversas abordagens da ES, como, por exemplo, o desenvolvimento ágil (GREER; HAMON, 2011), processo uni-ficado (HURER, 2002) e análise estruturada de sistemas (CIFUENTES; LOCKWOOD, 1996). Apesar dessa diversidade, autores como Perseil (2011) afirmam que os métodos de ES não são suficientemente flexíveis para incorporar as diversas inovações de mercado que sur-gem constantemente.

No entanto, como lembram Fernandes e Duarte (2005), mesmo considerando novas tecnologias e um cuidado com o dimensionamento de tempo e orçamento do projeto, o pro-cesso de desenvolvimento de software deve se orientar prioritariamente nas necessidades do cliente.

1.3.3 Geradores de código

(21)

1.4 DELIMITAÇÃO DO PROBLEMA

Em certas situações, no entanto, as abordagens atuais para desenvolvimento de softwa-re podem não ser suficientes para abordar as questões softwa-relativas a mudanças tecnológicas, am-bientes de múltiplas plataformas, interoperabilidade, mudanças frequentes nos requisitos, exi-gências sobre os produtos de software. Por exemplo, quando uma nova tecnologia está dispo-nível, não seria necessária uma nova modelagem para um novo sistema com funcionalidades semelhantes a outros existentes, visto que os modelos já produzidos com as respectivas regras podem ser reutilizados (SINGH; SOOD, 2009).

Assim, o uso do desenvolvimento por modelos tem como premissa dar suporte a pro-blemas como integração, portabilidade e interoperabilidade, pois continuamente surgem novas tecnologias e plataformas, que podem resultar em um maior esforço para sua utilização e de-correntes restrições (CHITFOROUSH; YAZDANDOOST; RAMSIN, 2007).

A construção de um software envolve várias etapas, processos e artefatos. Segundo Gao, Li e Zheng (2006), um relatório da Computer Weekly of America, nos EUA, mostra que

mais de 52% dos projetos de software excedem o orçamento previsto, decorrendo disso o can-celamento de 31% desses projetos. Assim, alguns questionamentos podem ser comuns em diversas empresas de software antes do início de novos projetos, por exemplo: Como prover um software com menor custo de construção e manutenibilidade, maior qualidade e em menor tempo atendendo as necessidades do usuário e/ou cliente? Qual o método de desenvolvimento mais adequado? Novas abordagens são necessárias? Minha organização está preparada para uma mudança de paradigma? Com base nesse contexto, identifica-se o seguinte problema de pesquisa: Como identificar os elementos relevantes para subsidiar a decisão sobre a ado-ção da abordagem de desenvolvimento de software baseada em modelos? Esta pesquisa se justifica pela busca de subsídios que apoiem as organizações de desenvolvimento de sof-tware na adoção de novas abordagens e/ou mudanças de abordagem.

1.5 MOTIVAÇÃO

Segundo Kleppe, Warmer e Bast (2003), mesmo com os inúmeros avanços na área de construção de software, ainda existem problemas com a maneira que o software é desenvolvi-do em grande parte das organizações, dentre os quais se destacam:

(22)

 Reutilização de conhecimento: além de ser um conjunto de linhas de instruções ordena-das e comandos que representam um algoritmo para um computador, o código-fonte concretizam um conhecimento já consolidado;

 Produtividade: o desenvolvimento de software, em sua maioria, é constituído de análise e codificação. Artefatos de alto nível (modelos e diagramas, por exemplo) são produzi-dos antes da codificação e servem de auxílio às tarefas de implementação e manutenção, mas não constituem o software propriamente dito;

 Manutenção e documentação: criar uma documentação de maneira correta e atualizada é uma das tarefas mais importantes para que um projeto de software sobreviva e evolua;  Portabilidade: a indústria de software é dinâmica, e novas tecnologias e plataformas

surgem constantemente, oferecendo novas funcionalidades, forçando as organizações a se adaptarem com maior velocidade para não ficarem desatualizadas em relação aos seus concorrentes;

 Interoperabilidade: sistemas de software esporadicamente funcionam de maneira isola-da. Normalmente eles precisam se comunicar (para trocar informações ou realizar tare-fas em conjunto).

Para Lucredio (2009), o desenvolvimento de software baseado em modelos (MDD –

Model-Driven Development) surgiu com o objetivo de reduzir alguns dos problemas citados

acima. Essa abordagem se propõe a fazer com que o engenheiro de software não precise in-tervir de forma manual com todo o código-fonte, podendo se concentrar em um nível mais alto através de modelos. Os modelos não são apenas um guia ou uma referência (participam em todo o processo); eles fazem parte do software, assim como o código-fonte.

As principais vantagens do MDD estão relacionadas aos problemas destacados anteri-ormente (KLEPPE; WARMER; BAST, 2003):

 Portabilidade: um mesmo modelo pode ser transformado em código, independente de plataforma;

 Interoperabilidade: cada parte de um modelo pode ser transformado em código para uma plataforma diferente, resultando em um software executado em um ambiente hete-rogêneo, porém mantendo a sua característica global. Também podem ser gerados me-canismos para se adaptar e/ou conectar esses códigos de diferentes plataformas, facili-tando a comunicação;

(23)

modelo requer a transformação manual para reutilizar também o código a ele associado. No MDD, isto se torna mais simples, pois o código pode ser automaticamente regerado para a nova situação;

 Corretude: além do fato de geradores não introduzirem erros acidentais (erros de digita-ção, por exemplo), estes permitem que a identificação de erros conceituais aconteça em um nível mais alto de abstração.

As vantagens do MDD se baseiam em evitar que o desenvolvedor precise executar as tarefas repetitivas necessárias para a transformação de modelos para o código final executá-vel. De acordo com Lucredio (2009), isto é alcançado através da automação dessas transfor-mações. O tempo gasto nessas tarefas, que no desenvolvimento convencional (o desenvolvi-mento não orientado a modelos) se deixa de lado a execução do ciclo completo dos requisitos aos testes, é expressivamente reduzido, fazendo que mesmo as atividades de urgência (corre-ção de erros) possam ser executadas sem gerar inconsistências com os modelos, e mantendo-os sempre atualizadmantendo-os.

Assim como qualquer abordagem para desenvolvimento, o MDD traz também algu-mas desvantagens, citadas por autores como Ambler (2003 apud LUCREDIO, 2009) e Tho-mas (2004 apud LUCREDIO, 2009), tais como:

 Rigidez: o MDD ocasiona maior rigidez na produção de software, uma vez que grande parte do código é gerada automaticamente, ficando fora do alcance do desenvolvedor;  Complexidade: os artefatos propostos para uma abordagem baseada em modelos (por

exemplo, modelos para transformações em outros modelos) adicionam complexidade ao processo, pois se tratam de artefatos inerentemente mais difíceis de construir e manter;  Curva de aprendizado: o desenvolvimento de artefatos específicos para o MDD exige

profissionais com habilidades na construção de linguagens, ferramentas de modelagem, transformações e geradores de código. O aprendizado destas técnicas, mesmo não sendo algo complexo, exige um treinamento específico.

1.6 OBJETIVOS

O objetivo geral desta pesquisa é propor fatores de apoio à decisão de uma organiza-ção rumo à oporganiza-ção pelo método de desenvolvimento de software orientado por modelos.

Para se alcançar tal objetivo, vislumbram-se os seguintes objetivos específicos: (i)

identificar, a partir da revisão bibliográfica, os fatores favoráveis à adoção do MDD, (ii)

(24)

estudo prático com o MDD, (iii) propor uma abordagem de avaliação de organizações

desen-volvedoras de software, com base no estudo bibliográfico e estudo prático, e (iv) exercitar a

(25)

2 REFERÊNCIAL TEÓRICO

Neste capítulo, serão tratados os conceitos que balizam esta pesquisa, a saber: (i) a

no-ção de modelo, (ii) os conceitos envolvidos no MDD, (iii) a caracterização das ferramentas de

desenvolvimento baseadas nesses conceitos, (iv) algumas aplicações do MDD em conjunto

com outras tecnologias/abordagens e a (v) relevância dos métodos baseados em modelos.

2.1 A NOÇÃO DE MODELO

Como regra geral, um modelo é um conjunto de declarações sobre algum sistema em estudo. Para permitir que os usuários de um modelo se concentrem sobre os aspectos signifi-cativos do sistema, qualquer modelo útil irá apresentar alguma forma de abstração do sistema em estudo. Uma forma de abstração, a redução, é a distinção das propriedades relevantes, irrelevantes ou aleatórias. Outras formas importantes de abstração são a generalização e a classificação. A generalização é um meio pelo qual as diferenças entre os elementos seme-lhantes são ignoradas para formar uma entidade em que as semelhanças podem ser enfatiza-das. A classificação é o processo de identificação de tipos, também conhecidos como concei-tos. A classificação é a forma básica de abstração encontrada na modelagem orientada a obje-tos ou baseada em objeobje-tos, onde os tipos de objeobje-tos são os elemenobje-tos principais de modelos conceituais (BEYDEDA; BOOK; GRUHN, 2005). Um exemplo de modelo de casos de uso é apresentado na Figura 1.

As noções de modelos, modelagem e transformação de modelos são a base para o con-junto de abordagens de desenvolvimento de software conhecido como Model-Driven Deve-lopment (MDD). As técnicas model-driven fornecem gerenciamento, transformação e

(26)

Figura 1. Modelo de casos de uso

Fonte: O Autor

2.2 TEORIAS DE BASE DO MDD

Com o objetivo de esclarecer os conceitos apresentados no trabalho e facilitar o enten-dimento do tema de pesquisa, a seguir é apresentada uma breve explanação dos pontos princi-pais no contexto do tema abordado.

2.2.1 Acerca do MDA

Model Driven Architecture (MDA) é uma maneira de especificar e construir sistemas.

Essa abordagem é baseada na modelagem, utilizando a UML, suportando o ciclo de vida completo de desenvolvimento de software (análise, projeto, desenvolvimento, implantação, implementação, manutenção, evolução e integração com sistemas posteriores). Ela se aplica diretamente a um ambiente misto (linguagens de programação, sistemas operacionais, rede, etc.), conforme estrutura da Figura 2.

(27)

Figura 2. Estrutura do MDA

Fonte: MDA (2011)

Basicamente, o MDA tem como objetivo a portabilidade e a interoperabilidade de aplicações através do uso de modelos que utilizem linguagens formais. Para a Object Mana-gement Group (OMG, 2003), o MDA tem como promessa permitir em longo prazo a

flexibi-lidade de:

 Implementação: uma nova infraestrutura de implementação pode ser integrada ou orien-tada por projetos existentes;

 Integração: uma vez que não apenas a implementação, mas o projeto como um todo, é passível de integração com outras estruturas, pode-se automatizar a produção de pontes de integração de dados e a ligação com as infraestruturas de integração de novos proje-tos;

 Manutenção: a disponibilidade do projeto em uma forma legível por máquina viabiliza, aos programadores, acesso direto à especificação do sistema, o que pode simplificar o processo de manutenção.

Para Hamou-Lhadj, Gherbi e Nandigam (2009), o MDA pode ser considerado uma das abordagens mais abrangentes na ES, por promover a separação do projeto do sistema de sof-tware a partir de sua implementação, garantindo a implantação de um sistema em várias plata-formas sem a alteração do projeto.Os conceitos chave são representados na Figura 3:

Platform Independent Model (PIM): Um PIM representa as funcionalidades do sistema,

(28)

PIM exibe um grau de independência de plataforma, de modo a se adequar a diferentes plataformas;

Platform Specific Model (PSM): Um PSM é uma visão de um sistema a partir do ponto

de vista de uma plataforma específica. Um PSM combina as especificações do PIM com os detalhes sobre como esse sistema utiliza um tipo particular de plataforma;

Model Transformation: Processo de conversão entre modelos do mesmo sistema. O

PIM e outras informações são combinados para produzir um PSM.

Figura 3. Conceitos chave do MDA

Fonte: Adaptado de HAMOU-LHADJ, GHERBI e NANDIGAM (2009, p. 720)

Os demais elementos do MDA citados pela OMG (2003), tais como System, Model, Model-Driven, Architecture, Viewpoint, View, Platform, Application, Platform Independence, The Computation Independent Model (CIM), Platform Model, Pervasive Services e Imple-mentation, explicitados no glossário ao final do trabalho.

2.2.2 Unified Modeling Language

O objetivo da Unified Modeling Language (UML) é proporcionar aos envolvidos na

construção de software, ferramentas para análise, concepção, implementação de software, bem como para a modelagem de negócios e processos similares. Apesar de ter a proposta de ser genérico, podendo trabalhar com qualquer linguagem de modelagem, o MDA tem grande foco na UML, sendo apenas uma das possíveis linguagens de modelagem que podem ser usa-das no desenvolvimento por modelos (OMG, 2011c; OMG, 2011d).

Platform Specific Model

(PSM)

Platform Independent Model (PIM)

Código da Aplicação

Model Transformation

(29)

2.2.3 Meta Object Facility

O Meta Object Facility (MOF) é a base do MDA. O MOF é um framework de

integra-ção orientado a modelos para a definiintegra-ção, manipulaintegra-ção e integraintegra-ção de metadados e dados de uma maneira independente de plataforma, representado por uma estrutura de texto linear. Usualmente se cria um arquivo padrão com marcadores para extrair os dados dos modelos. Estes marcadores são essencialmente expressões especificadas sobre as entidades do metamo-delo com consultas, sendo os principais mecanismos para selecionar e extrair os valores dos modelos.

Padrões baseados em MOF são utilizados para a integração de ferramentas, aplicativos e dados. É baseada em uma simplificação das capacidades da UML de modelagem de classes. Além de proporcionar os meios para a definição de um metamodelo, adiciona capacidades essenciais para a gestão de modelos em geral, incluindo identificadores, tags genéricas

sim-ples e operações definidas genericamente, podendo ser aplicadas independentemente do me-tamodelo (OMG, 2011b).

Segue na Figura 4 a utilização do MOF na especificação para a geração de um código Java por meio de uma definição de uma classe UML.

Figura 4. Exemplo de definições de extração de dados para linguagem JAVA

Fonte: OMG (2008, p. 3)

2.2.4 XML Metadata Interchange

(30)

pa-ra os modelos de compartilhamento usando XML. Define uma estrutupa-ra de documento que considera a relação entre os dados e seus correspondentes metadados, conforme exemplo da Figura 5.

Figura 5. Exemplo de um documento XMI

Fonte: OMG (2011e, p. 10)

Considera também muitos dos aspectos envolvidos na descrição de objetos em um XML, tais como a representação de objetos em termos de elementos e atributos XML. O XMI inclui mecanismos padrão para vincular objetos dentro do(s) mesmo(s) arquivo(s), visto que os objetos normalmente são interligados. A identidade de objeto permite que objetos sejam referenciados a partir de outros objetos em termos de identificadores (IDs) e a validação de documentos XMI com o uso esquemas XML (OMG, 2011e).

2.2.5 Object Constraint Language

O Object Constraint Language (OCL) é uma linguagem formal utilizada para

(31)

2.2.6 Query/View/Transformation

O QVT (Query/View/Transformation) define uma linguagem textual e uma notação na

definição de consultas e transformações baseadas no MOF. Por meio da QVT, é possível de-finir regras de mapeamento entre modelos escritos em diferentes linguagens de modelagem, desde que esta seja uma instância do MOF. Os conceitos em que se baseia a sigla são: Query -

ter um modelo como entrada e selecionar elementos específicos desse modelo, View -

mode-los derivados de outros modemode-los, e Transformation - utilizar ou atualizar um modelo existente

ou criar um novo modelo (OMG, 2011a).

2.3 FERRAMENTAS DE DESENVOLVIMENTO

Com o objetivo de esclarecer questões sobre qual ferramenta escolher para aplicar os conceitos apresentados no trabalho, a seguir são apresentadas algumas ferramentas para apli-cação do MDD.

2.3.1 AndroMDA

O AndroMDA é um framework open source de geração de código baseado no MDA.

Utiliza modelos UML e uma série de plugins, chamados de cartuchos para realização de

gera-ção de artefatos, tais como código fonte, configurações, scripts, DLLs e outros. É preciso um

modelo UML construído em uma ferramenta CASE para gerar classes e componentes implan-táveis (J2EE ou outros) específicos para a sua arquitetura de aplicação. A arquitetura do An-droMDA permite o desenvolvimento rápido de cartuchos, assim como sua customização a nível de sistema (ANDROMDA, 2003a; 2012).

Com o AndroMDA, é possível utilizar qualquer quantidade de modelos combinada com qualquer número de seus plugins (cartucho e tradução de bibliotecas), produzindo um

número qualquer de componentes personalizados, geralmente modelos UML armazenados em XMI produzidos a partir de ferramentas CASE. É possível gerar componentes para qualquer linguagem (Java, .Net, HTML, PHP), tendo que criar ou personalizar os plugins existentes

(32)

2.3.2 Acceleo

O Acceleo foi projetado para melhorar a produtividade de desenvolvimento de softwa-re baseado no MDA. É utilizado para a geração de grande quantidade de código. Sua imple-mentação é feita por meio de métodos de prototipagem e validação da qualidade de software, por exemplo. Pode lidar com qualquer tipo de modelo, mas é particularmente eficiente para traduzir modelos de design de alto nível para a implementação de arquitetura complexa. Para

efetuar as transformações, o Acceleo usa o conceito de módulos, que são coleções de templa-tes que descrevem a informação necessária para gerar o código-fonte a partir de um

metamo-delo. Cada módulo é específico para uma tecnologia (Java, C#, PHP, etc.). Em cada template,

os scripts permitem que o usuário customize o gerador da forma que lhe convier. A

ta é compatível com XMI 1.x e XMI 2, o que garante a compatibilidade com outras ferramen-tas para a modelagem UML, como RSM, Together, Poseidon, etc. (ACCELEO, 2006).

2.3.3 Eclipse Modeling Framework

O Eclipse Modeling Framework (EMF) é um framework de modelagem e facilitador

na geração de código para ferramentas de construção e outras aplicações baseadas em um modelo estruturado de dados. A partir da especificação de um modelo descrito em XMI, o EMF fornece ferramentas e suporte em tempo de execução para produzir um conjunto de classes Java para o modelo, um conjunto de classes adaptadas que permitem a visualização e edição do modelo baseado em comandos e um editor básico. Os modelos podem ser especifi-cados usando a notação Java, documentos XML ou ferramentas de modelagem como Rational Rose que, em seguida, são importados para EMF. Sobretudo, o EMF fornece a base para a

interoperabilidade com outros EMF baseados em ferramentas e aplicações (EMF, 2012).

2.3.4 MoDisco

(33)

 Garantia de Qualidade: verificação do sistema de acordo com os requisitos previstos (detecção de antipadrões, cálculo de métricas, etc.);

 Documentação: extração de informações para facilitar a compreensão de um determina-do aspecto (estrutura, comportamento, persistência, de fluxo de dadetermina-dos, etc.);

 Melhoria: transformação de um sistema existente para melhor integrar as normas de co-dificação ou utilizar padrões de projeto mais eficientes;

 Migração: transformação de um sistema existente para alterar um componente,

fra-mework, linguagem ou a sua arquitetura.

2.4 ALGUMAS APLICAÇÕES DO MDD

Diversos trabalhos abordaram o uso do MDD. Alguns deles são comentados a seguir. Uma possível aplicação é a utilização de Web Services aliada às técnicas de desenvolvimento

orientado por modelos. O objetivo deste tipo de aplicação é a utilização da UML, especifican-do os serviços de forma independente de tecnologia baseanespecifican-do-se em requisitos de negócios rastreáveis, para a modelagem do Web Services – transformando os modelos UML em

arqui-vos WSDL e, a partir desses arquiarqui-vos, gerar código Java. Nesse sentido, apenas as ferramen-tas Sparx Enterprise Architect e AndroMDA suportam a geração WSDL e XSD

(QAFMOL-LA; CUONG, 2010). Qafmolla e Cuong (2010), apresentam uma abordagem para automatizar o desenvolvimento para Web Services utilizando o MDA. Para isso, diversas ferramentas

fo-ram mostradas em cada fase do processo. Apresentam ainda a visão de um maior nível de abstração, introduzindo a transformação de um metamodelo utilizando a linguagem orientada a objetos Kermeta. Afirmando que ao aumentar o nível de abstração se pode diminuir ou evi-tar problemas no contexto de mudanças do sistema. E sugerindo que as técnicas de automati-zação de transformações de modelos e gerações de código podem ser adequadas para situa-ções similares a esta.

(34)

siste-mas que utilizam a programação orientada a aspectos (ZHANG et al., 2009). Para o autor, a POA pode separar os requisitos funcionais dos não-funcionais, e aliada ao MDA pode resol-ver separadamente os problemas de aspectos funcionais e não-funcionais na construção de um software. Observa ainda que apesar do grande número de métodos encontrados para a trans-formação de modelos, não existe um padrão uniforme para mapear PIMs em PSMs no contex-to da orientação a aspeccontex-tos, e não existem ferramentas de MDA para apoio à Modelagem Ori-entada a Aspectos.

Novas tecnologias e plataformas estão surgindo no desenvolvimento de software de maneira contínua, resultando em um grau de esforço maior para fazer uso dos novos recursos que o mercado oferece, bem como satisfazer as restrições que ele impõe. Outra iniciativa de pesquisa, objetivando suprir essa necessidade, diz respeito às metodologias orientadas por modelos no desenvolvimento de software. Dentre elas tem-se, por exemplo, o MODA-TEL, proposto como um processo de desenvolvimento de software baseado em princípios e concei-tos do MDA. Apesar do MODA-TEL ser voltado para aplicações distribuídas, ele é suficien-temente genérico para ser aplicável a outros domínios e situações (CHITFOROUSH; YAZDANDOOST; RAMSIN, 2007).

MIDAS é uma estrutura metodológica orientada para o desenvolvimento ágil de Sis-temas de Informação Web, onde a UML é usada para representar os diferentes PIMs e PSMs

propostos neste framework, definindo também regras de mapeamento para transformação de

modelos (CHITFOROUSH; YAZDANDOOST; RAMSIN, 2007). Para os autores, muito se investiu no MDA, porém metodologias de suporte para o desenvolvimento por modelos não se obteve a mesma atenção. Eles afirmam que há poucas metodologias de desenvolvimento de software baseadas no MDA e propõem um quadro de metodologias baseadas no MDA a se-rem utilizadas no desenvolvimento de software, permitindo que as organizações continuem utilizando suas metodologias atuais, melhorando-as com as capacidades do MDA, quando necessário.

Combinar as práticas de desenvolvimento por modelos com as técnicas ágeis pode re-duzir significativamente o tempo de ciclo de desenvolvimento de software e aumentar a pro-dutividade e qualidade. Nesse contexto, Zhang e Patel (2011), aliaram SLAP, um processo ágil que utiliza Scrum e divide um ciclo de vida de desenvolvimento em múltiplas iterações,

ao MDD, gerando um MDD ágil. Desta forma, uma iteração em MDD ágil é composta por três Sprints. Um Sprint para especificação de requisitos e arquitetura, um para

(35)

e testes do sistema. Esta técnica foi aplicada no desenvolvimento de um sistema de telecomu-nicações para geração automática de código utilizando a UML para modelagem. Para os auto-res, do ponto de vista do MDD, a chave é maximizar a automação utilizando as ferramentas para o MDD permitindo o desenvolvimento livre de erro (de alta qualidade) e aumento signi-ficativo de produtividade, já do ponto de vista ágil, a chave é alcançar iterações de forma efi-ciente desde a engenharia até o teste do sistema.

Um fator importante no desenvolvimento de software diz respeito às métricas. A mé-trica, no contexto do MDA, oferece uma abordagem prática para avaliar as propriedades de modelos específicos de domínio. No entanto, muitas vezes é dispendioso desenvolver e man-ter um software de medição para cada linguagem de modelagem específica de domínio. Para isso, Monperrus et al. (2010) apresenta uma abordagem por modelos (model-driven) em

con-junto com uma ferramenta geradora de modelos para medição. A abordagem é completamente independente de domínio e operacionalizada via um protótipo que sintetiza uma infraestrutura de medição para uma linguagem de modelagem específica de domínio. A definição de métri-cas por modelos consiste na construção de métrimétri-cas de especificações que permite instanciar o metamodelo de especificação métrica. Estas especificações referem-se aos elementos de um metamodelo de domínio e define métricas em uma forma puramente declarativa. O autor afirma que a abordagem por modelos em conjunto com a medição permite adicionar automa-ticamente capacidades de medição para uma linguagem de modelagem específica de domínio. A abordagem foi validada por meio da especificação de mais de 100 métricas em domínios diferentes, tais como código-fonte, arquitetura de software, engenharia de sistemas e requisi-tos.

2.5 RELEVÂNCIA DOS MÉTODOS BASEADOS EM MODELOS

Para Fowler (2004), a importância dos modelos no desenvolvimento de software é um fato. Segundo esse autor, eles permitem um alto grau de abstração no desenvolvimento de sistemas e facilita o planejamento e o entendimento da solução em construção. Com isso, a abordagem por modelos permite “fazer um desenho” dos recursos e funcionalidades desejados a partir de um conjunto de modelos.

Modelos, como abstrações que descrevem os elementos de um sistema, são os princi-pais artefatos dessa forma de desenvolvimento, e não o código. No entanto, como em qual-quer abordagem de desenvolvimento, existem pontos positivos e negativos.

(36)

tais como a possibilidade de reuso de componentes, a facilidade de gerar código diretamente a partir de diagramas, a separação da lógica de negócio da lógica de aplicação em uma determi-nada tecnologia, independência de plataformas, fazendo com que lógica do negócio possa evoluir de forma independente de tecnologia, número considerável de ferramentas que im-plementam os conceitos de desenvolvimento por modelos, etc.

Em contrapartida, alguns possíveis pontos negativos podem ser destacados, tal como a incompletude das ferramentas quanto aos conceitos da abordagem incorporados. É preciso, portanto, analisar a real correspondência entre os conceitos do MDD presentes antes de se escolher por uma ou outra ferramenta. Outro aspecto negativo é que, além de manter os códi-gos gerados, é necessário também dar manutenção aos respectivos modelos ao longo de todo o projeto.

(37)

3 ASPECTOS METODOLÓGICOS

Neste capítulo, serão tratados os aspectos que estão relacionados à metodologia em-pregada no trabalho de pesquisa, a saber: (i) classificação da pesquisa e as (ii) etapas do

traba-lho de pesquisa.

3.1 CLASSIFICAÇÃO DA PESQUISA

Método, de acordo com Wazlawick (2008), consiste em uma sequência de passos ne-cessários para demonstrar que o objetivo proposto foi atingindo. Ou seja, uma vez definido o objetivo, o método irá descrever o caminho para atingi-lo. Pesquisa, para Máttar Neto (2002), é um processo de descoberta e de invenção, onde há um elemento de criatividade, lúdico, que está envolvido na atividade de investigação científica.

Este trabalho de pesquisa é orientado por uma avaliação qualitativa. Segundo Martins (2008), essa abordagem se caracteriza pela descrição, compreensão e interpretação de fatos e fenômenos. Este trabalho é não experimental, por consistir em um estudo sem a intervenção sistemática de um pesquisador (WAZLAWICK, 2008).

Este estudo partiu de ensinamentos advindos do referencial teórico e das característi-cas do próprio característi-caso. A partir da literatura técnico-científica, se buscou evidenciar as caracte-rísticas das técnicas empregadas no desenvolvimento por modelos. Os resultados desse levan-tamento bibliográfico foram confrontados com os recursos oferecidos pelas ferramentas de desenvolvimento baseadas em modelos citadas no capítulo anterior (ACCELEO, AndroMDA e EMF). As informações levantadas junto às organizações em estudo, sobre os elementos em-pregados que podem levar à escolha por uma ou outra técnica/ferramenta de desenvolvimento.

3.2 ETAPAS DO TRABALHO DE PESQUISA

O trabalho foi realizado em oito etapas, descritas a seguir.

ETAPA 1:

OBJETIVO: Criar uma lista preliminar de fatores que sugerem o alinhamento da orga-nização ao MDD.

(38)

de software orientado por modelos. Criou-se uma lista preliminar com os fatores candidatos a este alinhamento.

PRODUTOS: Lista contendo os fatores, a suas descrições e os autores que a ele se refe-rem.

ETAPA 2:

OBJETIVO: Exercitar o MDD, através da produção de um software utilizando a abor-dagem, para obter, no âmbito prático, um melhor entendimento dos fatores que favo-recem o alinhamento à abordagem.

INSUMOS: Lista de fatores produzida na etapa 1.

ATIVIDADES: Por meio do uso de uma ferramenta adequada ao desenvolvimento por modelos, foram vivenciados os fatores evidenciados no referencial bibliográfico para possíveis inclusões de novos fatores e/ou ajustes nos fatores previamente identifica-dos. Após o exercício do MDD, foram ratificados e incluídos fatores com as evidên-cias encontradas nesta etapa.

PRODUTOS: Lista de fatores produzida na etapa 1 atualizada.

ETAPA 3:

OBJETIVO: Propor um instrumento que permita avaliar se uma determinada organiza-ção desenvolvedora de software tem características favoráveis à adoorganiza-ção do MDD. INSUMOS: Lista de fatores da etapa 2.

ATIVIDADES: Foi criada uma lista relacionando sugestões de perguntas aos fatores previamente identificados, com sua respectiva justificativa, buscando evidenciar ca-racterísticas que possam ser encontradas na organização que sugerem o alinhamento ao MDD. A partir dessa lista, criou-se um questionário, onde cada questão foi relaci-onada aos insumos desta etapa, e suas respectivas respostas estão na escala Likert (MARTINS, 2008, p. 41-44). Por ser um questionário preliminar, para cada questio-namento solicitou-se ao respondente um retorno crítico, de forma subjetiva, para ve-rificar sua clareza e objetividade.

PRODUTOS: Uma lista com perguntas, suas justificativas e os fatores relacionados. E uma versão inicial do questionário de avaliação do alinhamento da organização ao MDD.

ETAPA 4:

(39)

dados para posterior aprimoramento.

INSUMOS: Versão inicial do questionário de avaliação do alinhamento da organização ao MDD produzido na etapa 3.

ATIVIDADES: Foram selecionadas organizações, que atuem na área de tecnologia e/ou que tenham área específica para TI, que desenvolvam software e que utilizem pro-cessos de desenvolvimento em seus projetos, para a participação na pesquisa. Com o propósito de avaliar o questionário, foram escolhidos profissionais, com envolvimen-to no contexenvolvimen-to da ES, de uma das organizações selecionadas nesta etapa para avaliar, a partir do retorno crítico dos respondentes, as questões do questionário observando sua consistência e aplicabilidade. Foram catalogados os comentários e/ou sugestões de ajustes dos respondentes às questões.

PRODUTOS: Empresas selecionadas para participação na pesquisa. Lista com os co-mentários e/ou sugestões de ajustes dos respondentes para cada questionamento.

ETAPA 5:

OBJETIVO: Aprimorar o questionário baseando-se na lista de comentários dos respon-dentes do pré-teste da etapa 4.

INSUMOS: Versão inicial do questionário da etapa 3 e a lista com os comentários dos respondentes produzida na etapa 4.

ATIVIDADES: Foram alteradas as questões propostas conforme a análise realizada, ge-rando uma nova versão do questionário. Ainda nesta versão, o retorno crítico de cada questionamento foi alterado para a forma objetiva, assim, possibilitando verificar continuamente a clareza e objetividade da nova versão.

PRODUTOS: Nova versão do questionário de pesquisa.

ETAPA 6:

OBJETIVO: Com base no pré-teste, selecionar os perfis dos profissionais da organiza-ção para aplicaorganiza-ção efetiva do questionário aprimorado da etapa 5 nas organizações. ATIVIDADES: Foi realizada uma coleta de informações sobre o perfil dos profissionais

(40)

PRODUTOS: Formulário para coleta de informações de perfil. Lista de profissionais se-lecionados, de cada organização, que irão responder o questionário da etapa 5.

ETAPA 7:

OBJETIVO: Realizar a aplicação efetiva do questionário produzido na etapa 5. INSUMOS: Questionário da etapa 5 e lista de selecionados da etapa 6.

ATIVIDADES: Foi aplicado o questionário, em sua versão aprimorada, nas organiza-ções selecionadas na etapa 4. Para isso, foram três as organizaorganiza-ções envolvidas nesta fase, onde os profissionais, para cada organização, foram selecionados na etapa ante-rior. Foram ainda coletados os dados para apresentação gráfica suas respectivas con-solidações.

PRODUTOS: Apresentação gráfica, por organização, dos dados consolidados.

ETAPA 8:

OBJETIVO: Analisar as informações gráficas consolidadas na etapa anterior. INSUMOS: Dados consolidados da etapa 7.

ATIVIDADES: Foram analisados os resultados da pesquisa, identificando-se (conforme premissas do MDD) e apresentando-se os fatores que sugerem o alinhamento de uma organização com a abordagem de desenvolvimento orientada a modelos.

(41)

4 REALIZAÇÃO DA PESQUISA

Neste capítulo, será tratada a forma como foi executada cada etapa da pesquisa, a sa-ber: (i) fatores para alinhamento ao MDD, (ii) exercício prático do MDD, (iii) criação do

ins-trumento de pesquisa, (iv) pré-teste do questionário de pesquisa, (v) análise do pré-teste e

ajustes no questionário, (vi) seleção dos profissionais de TI das organizações, (vii) aplicação

do questionário de pesquisa e (viii) análise dos resultados da aplicação do instrumento de

pes-quisa.

4.1 FATORES PARA ALINHAMENTO AO MDD

(42)

Quadro 1. Fatores candidatos ao alinhamento do MDD

FATOR DESCRIÇÃO REFERÊNCIAS

1 – Baseado na

modelagem O MDD tem como base a modelagem, modelosou diagramas que expliquem as características ou o comportamento de um software.

HAILPERN; TARR, 2006. OMG, 2003. SELIC, 2006. 2 – Modelos no ciclo de

vida de software

No MDD os modelos são os artefatos centrais no contexto de desenvolvimento de software, pois são utilizados, e consequentemente mantidos, em todas as fases do ciclo de vida de desenvolvimento de software.

GAO; LI; ZHENG, 2006. LUCRÉDIO, 2009. ZHANG et al., 2009.

3 – Modelos de alto nível No MDD se utiliza modelos de alto nível conceitual, mostrando a conceituação do mundo real em um alto nível de abstração.

LUCRÉDIO, 2009. PARREIRAS, 2012.

QAFMOLLA; CUONG, 2010. SINGH; SOOD, 2009. ZHANG et al., 2009.

4 – Portabilidade No MDD um modelo pode ser transformado em código independente de tecnologia, por tanto não necessita de vincular-se a tecnologia que estará em uso no produto final.

ELLEUCH; KHALFALLAH; AHMED, 2007. HAMOU-LHADJ; GHERBI;

NANDIGAM, 2009. KLEPPE; WARMER; BAST, 2003. SINGH; SOOD, 2009. 5 – Interoperabilidade O MDD permite a integração de diferentes

plataformas. Por meio de sua independência é possível gerar mecanismos para adaptar e/ou conectar códigos de diferentes plataformas.

CHITFOROUSH;

YAZDANDOOST; RAMSIN, 2007. KLEPPE; WARMER; BAST, 2003. QAFMOLLA; CUONG, 2010. SINGH; SOOD, 2009.

Fonte: O Autor

4.2 EXERCÍCIO PRÁTICO DO MDD

Com o objetivo de obter melhor entendimento do MDD no âmbito prático, foi exerci-tada a abordagem. Para este exercício, foi utilizada a ferramenta Acceleo1, já citada na seção 2.3.2, para a implementação do MDD, integrada a IDE Eclipse2. Na Figura 6 temos a repre-sentação do fluxo de trabalho com o Acceleo.

Para iniciar o exemplo do uso do MDD por meio do Acceleo, foi criado um diagrama de casos de uso, visto na Figura 7, que descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário, visando o alto nível conceitual, isto é, buscando criar um diagrama de fácil entendimento do usuário, auxiliando, assim, a comunicação entre analis-tas e clientes. Este diagrama representa o PIM, uma representação inerente a plataforma onde o sistema será desenvolvido. A partir do diagrama de casos de uso foi criado o diagrama de classes mostrado na Figura 8.

(43)

Figura 6. Esquema de utilização do Acceleo

Fonte: Acceleo (2006)

Figura 7. Exemplo de diagrama de casos de uso

(44)

Figura 8. Exemplo de diagrama de classes

Fonte: O Autor

A Figura 8 descreve os tipos de objetos no sistema e o relacionamento entre eles. A transformação de modelos em outros modelos é uma das características do MDD. Com isso, é possível criar características específicas para a criação de código-fonte, aqui por meio dos atributos e métodos das classes. Este diagrama representa o PSM, uma visão do sistema a par-tir do ponto de vista de uma plataforma específica, para o exemplo, o PHP.

No Acceleo, tem-se a geração automática do arquivo .uml no momento da criação dos

diagramas, este arquivo é escrito no padrão XMI, que define a estrutura de documento, ser-vindo como intercâmbio de dados UML, mostrado nas figuras 9 e 10.

A transformação automática de um diagrama em código também é possível. Para isso, faz-se necessário um mecanismo que interprete o XMI e traduza o diagrama para a linguagem de programação escolhida. No contexto do MDD, é escrito conforme o padrão MOF (OMG, 2008), transformando o modelo em linguagem de texto. No ambiente Acceleo, por exemplo, os conceitos de Model Transformation e MOF são traduzidos para um template, um arquivo

(45)

Figura 9. Edição visual do XMI

Fonte: O Autor

Figura 10. Estrutura do XMI

(46)

Figura 11. Exemplo de um template do Acceleo

Fonte: O Autor

O template mostrado traz instruções para criar arquivos com classes, atributos e

méto-dos na linguagem de programação PHP de acordo com o diagrama representado na Figura 8. Para se gerar um arquivo em outra linguagem com o mesmo diagrama, bastaria alterar a ex-tensão do arquivo de saída (de “.php” para “.java”, por exemplo) e a estrutura da codificação da linguagem escolhida. Entretanto, instruções como p.visibility e c.attribute não sofreriam alterações, possibilitando a geração de uma nova versão do sistema não só para diferentes plataformas como também para novas tecnologias.

No Acceleo, por exemplo, é possível criar um template para cada linguagem escolhida

(47)

Figura 12. Exemplo de código PHP gerado pelo Acceleo

Fonte: O Autor

No exemplo em questão, o código-fonte de todos os objetos existentes no diagrama da Figura 8 foi gerado automaticamente. Na Figura 12 é apresentado um exemplo de produto gerado.

Com o exercício prático da abordagem foi possível compreender melhor os conceitos de portabilidade, interoperabilidade e reutilização do MDD. Foi observado que a ferramenta serviu de suporte para automatizar as atividades de transformações sem a intervenção manual do desenvolvedor, em decorrência, acrescentado o fator Automatização das transformações à

(48)

Quadro 2. Atualização dos fatores candidatos para o alinhamento ao MDD

FATOR DESCRIÇÃO REFERÊNCIAS

1 – Baseado na modelagem

O MDD tem como base a modelagem, modelos ou diagramas que expliquem as características ou o comportamento de um software.

HAILPERN; TARR, 2006. OMG, 2003. SELIC, 2006.

2 – Modelos no ciclo de

vida de software No MDD os modelos são os artefatos centrais no contexto de desenvolvimento de software, pois são utilizados, e

consequentemente mantidos, em todas as fases do ciclo de vida de desenvolvimento de software.

GAO; LI; ZHENG, 2006. LUCRÉDIO, 2009. ZHANG et al., 2009.

3 – Modelos de alto nível No MDD se utiliza modelos de alto nível conceitual, mostrando a conceituação do mundo real em um alto nível de abstração.

LUCRÉDIO, 2009. PARREIRAS, 2012.

QAFMOLLA; CUONG, 2010. SINGH; SOOD, 2009. ZHANG et al., 2009.

4 – Automatização das transformações

No MDD evita-se que o desenvolvedor de software execute tarefas repetitivas para transformar modelos em código-fonte, fazendo que estas atividades sejam automatizadas, não necessitando de intervenção manual do desenvolvedor nas transformações dos modelos.

CHITFOROUSH;

YAZDANDOOST; RAMSIN, 2007. GAO; LI; ZHENG, 2006. LUCRÉDIO, 2009.

QAFMOLLA; CUONG, 2010. SELIC, 2006. SINGH; SOOD, 2009.

5 – Portabilidade No MDD um modelo pode ser transformado em código independente de tecnologia, por tanto não necessita de vincular-se a tecnologia que estará em uso no produto final.

ELLEUCH; KHALFALLAH; AHMED, 2007. HAMOU-LHADJ; GHERBI;

NANDIGAM, 2009. KLEPPE; WARMER; BAST, 2003. SINGH; SOOD, 2009. 6 – Interoperabilidade O MDD permite a integração de diferentes

plataformas. Por meio de sua independência é possível gerar mecanismos para adaptar e/ou conectar códigos de diferentes plataformas.

CHITFOROUSH;

YAZDANDOOST; RAMSIN, 2007. KLEPPE; WARMER; BAST, 2003. QAFMOLLA; CUONG, 2010. SINGH; SOOD, 2009.

Fonte: O Autor

4.3 CRIAÇÃO DO INSTRUMENTO DE PESQUISA

Imagem

Figura 1. Modelo de casos de uso
Figura 2. Estrutura do MDA
Figura 3. Conceitos chave do MDA
Figura 6. Esquema de utilização do Acceleo
+7

Referências

Documentos relacionados

Para disciplinar o processo de desenvolvimento, a Engenharia de Usabilidade, também conceituada e descrita neste capítulo, descreve os métodos estruturados, a

No final, os EUA viram a maioria das questões que tinham de ser resolvidas no sentido da criação de um tribunal que lhe fosse aceitável serem estabelecidas em sentido oposto, pelo

Para analisar as Componentes de Gestão foram utilizadas questões referentes à forma como o visitante considera as condições da ilha no momento da realização do

O TBC surge como uma das muitas alternativas pensadas para as populações locais, se constituindo como uma atividade econômica solidária que concatena a comunidade com os

Para avaliar a toxicidade dos compostos in vitro utilizou-se testes colorimétricos (MTT) em formas tripomastigotas (cepa Y) e em macrófagos J774A.1, além de ensaios

Nesse contexto, quando o indivíduo age de acordo com o princípio da utilidade, ele cuida de si mesmo através do cultivo da sua natureza humana esse cultivo é a expressão do amor

Local de realização da avaliação: Centro de Aperfeiçoamento dos Profissionais da Educação - EAPE , endereço : SGAS 907 - Brasília/DF. Estamos à disposição