CURSO DE TECNOLOGIA EM DESENVOLVIMENTO DE SOFTWARE ISABELA ALVES MANHÃES KAREN DA SILVA FIGUEIREDO LARISSA TEIXEIRA ROCHA

CURSO DE TECNOLOGIA EM DESENVOLVIMENTO DE SOFTWARE ISABELA ALVES MANHÃES KAREN DA SILVA FIGUEIREDO LARISSA TEIXEIRA ROCHA APLICANDO ABORDAGENS DE REUTILIZAÇÃO DE SOFTWARE NA CONSTRUÇÃO DE UM FRAMEWORK PARA O DOMÍNIO DE CATÁLOGO DE ESTABELECIMENTOS DO RAMO ALIMENTÍCIO Campos dos Goytacazes/RJ 2008

ISABELA ALVES MANHÃES KAREN DA SILVA FIGUEIREDO LARISSA TEIXEIRA ROCHA APLICANDO ABORDAGENS DE REUTILIZAÇÃO DE SOFTWARE NA CONSTRUÇÃO DE UM FRAMEWORK PARA O DOMÍNIO DE CATÁLOGO DE ESTABELECIMENTOS DO RAMO ALIMENTÍCIO Monografia apresentada ao Centro Federal de Educação Tecnológica de Campos como requisito parcial para conclusão do Curso de Tecnologia em Desenvolvimento de Software. Orientador: Profª. Aline Pires Vieira de Vasconcelos, D.Sc. Campos dos Goytacazes/RJ 2008

ISABELA ALVES MANHÃES KAREN DA SILVA FIGUEIREDO LARISSA TEIXEIRA ROCHA APLICANDO ABORDAGENS DE REUTILIZAÇÃO DE SOFTWARE NA CONSTRUÇÃO DE UM FRAMEWORK PARA O DOMÍNIO DE CATÁLOGO DE ESTABELECIMENTOS DO RAMO ALIMENTÍCIO Monografia apresentada ao Centro Federal de Educação Tecnológica de Campos como requisito parcial para conclusão do Curso de Tecnologia em Desenvolvimento de Software. Aprovada em 15 de setembro de 2008. Banca Avaliadora: Profª. Aline Pires Vieira de Vasconcelos, D.Sc. (Orientadora) Prof. Jonivan Coutinho Lisboa, M.Sc. Prof. Henrique Rego Monteiro da Hora, M.Sc.

AGRADECIMENTOS Isabela: À minha família e as das minhas amigas e companheiras neste projeto pela paciência, compreensão e apoio. Ao meu pai, Teobaldo Luiz Manhães (in memorian). Aos amigos, pessoais e virtuais, por continuarem sendo amigos apesar de todo o meu stress e por continuarem ao meu lado me apoiando e dando forças em todas as etapas da minha vida. À orientadora Aline, sempre muito atenciosa e exigente, fazendo nosso trabalho evoluir. E a Krishna acima de tudo. Karen: À professora, Aline, pela grande dedicação ao nos orientar neste projeto. À minha mãe e à minha avó, pelo carinho e atenção a mim dispensados durante todas as fases da minha vida, incluindo esta. A todos os meus amigos, que são para mim uma segunda família, por todo companheirismo e compreensão nos momentos difíceis. A Krishna, o controlador Supremo de todas as coisas, agradeço por permitir que eu alcance mais esta etapa da minha vida, a Ele todas as minhas humildes reverências! Larissa: Primeiramente, ao meu pai e à minha mãe, por estarem por perto e me apoiando incondicionalmente. Às minhas amigas Isabela e Karen, que também participaram deste projeto e foram primordiais para a sua conclusão. Aos amigos que sempre me incentivaram e ajudaram diretamente, como Arianne, Eleonora e todos com os quais eu pude contar. À professora Aline, também orientadora desta monografia, eu deixo meu agradecimento especial pelo esforço, apoio e paciência que teve até o final deste projeto, nos corrigindo e incentivado.

RESUMO O presente trabalho trata de algumas abordagens de destaque na literatura sobre reutilização de software e suas aplicações na construção de um framework para o domínio de Catálogo de Estabelecimentos do Ramo Alimentício. Para suportar este processo, é utilizado o ambiente de modelagem baseado em reutilização Odyssey, desenvolvido pela COPPE/UFRJ, bem como sua notação para modelagem de domínio Odyssey-FEX. O Catálogo de Estabelecimentos do Ramo Alimentício é o domínio escolhido para este estudo, pois as aplicações já existentes não atendem a todas as necessidades dos estabelecimentos e seus consumidores, levando a uma grande procura do mercado. Com o propósito de realizar esta análise, as técnicas de reutilização empregadas englobam a Engenharia de Domínio e suas etapas, tais como a Análise do Domínio, na qual são consideradas as opcionalidades e variabilidades dos sistemas do domínio, e o Projeto do Domínio, dando ênfase às técnicas de Frameworks. Destaca-se que para um projeto baseado em reutilização ser concluído com sucesso, obtendo-se o máximo de vantagens, é preciso que se aplique técnicas de reutilização desde o início do ciclo de vida do software, através de abordagens como a Engenharia de Domínio. Dessa forma, a reutilização de software pode levar a um desenvolvimento de software mais rápido, mais barato e de qualidade. Nesse contexto, este projeto visa realizar uma análise do domínio proposto, permitindo, a partir desta, gerar artefatos reutilizáveis de software, além da sua instanciação, demonstrando as vantagens que podem ser obtidas com a reutilização na prática. Palavras-chave: Reutilização de Software. Engenharia de Domínio. Frameworks. Catálogo de Estabelecimentos do Ramo Alimentício. Características e Variabilidades.

ABSTRACT This work presents some highlighted approaches about software reuse and their application on a framework construction for the domain of the Catalogue of Establishments of the Food Industry. To support this process, is used the environment based on reuse Odyssey, developed by the COPPE/UFRJ, and its domain modeling notation Odyssey-FEX. The Catalogue of Establishments of the Food Industry was the chosen domain for this study because the existing applications do not afford all the needs of establishments and their consumers, leading to a high demand of the market. In order to analyses this domain, the reuse techniques employed include the Domain Engineering and its stages, such as the Domain Analysis, which are considered the optionalities and the variabilities of the systems of a domain, and the Domain Project, emphasizing the frameworks. For a reuse based project be completed successfully, with the maximum of advantages, it s needed to apply reuse techniques since the beginning of the life cycle of the software, through approaches such as Domain Engineering. As a result, the software reutilization can lead to a faster, cheaper and qualified software development. In that context, this project involves a analysis of the proposed domain, allowing the development of reusable software artifacts, besides the instantiation of this domain, demonstrating the benefits that can be obtained from the practice of reuse. Keywords: Software Reuse. Domain Engineering. Frameworks. Catalogue of Establishments of the Food Industry. Features and Variabilities.

LISTA DE FIGURAS E TABELAS Figura 2.1 Ciclo de Vida da Engenharia de Domínio (OLIVEIRA, 2006)...18 Figura 2.2 Fases da Engenharia de Domínio (RADÜNZ, 2007)...19 Tabela 2.1 Tipos de Características na notação Odyssey-FEX (OLIVEIRA, 2006)...23 Tabela 2.2 Tipos de Características no ambiente Odyssey (OLIVEIRA, 2006)...24 Tabela 2.3 Tipos de Relacionamentos no ambiente Odyssey (MILER, 2000)...25 Figura 2.3 Modelo de características da notação Odyssey-FEX (WERNER, 2008)..26 Figura 2.4 Propriedades ortogonais da notação Odyssey-FEX (OLIVEIRA, 2006)...27 Figura 2.5 Ambiente Odyssey...29 Figura 2.6 Diferença entre biblioteca de classes e framework (SAUVÉ, 2002)...31 Figura 3.1 Página inicial do estabelecimento, com as cidades disponíveis (GUIA BARES, 2008)...36 Figura 3.2 Página que o site oferece de publicidade aos estabelecimentos cadastrados (GUIA BARES, 2008)...37 Figura 3.3 Página inicial do site do Guia dos Restaurantes (2008)...38 Figura 3.4 Opções de planos que o Guia dos Restaurantes (2008) disponibiliza...38 Figura 3.5 Página inicial do site RestauranteWeb (2008)...39 Figura 3.6 Página inicial do site BondGarfo (2008)...40 Figura 3.7 Página inicial do site Disk Cook (2008)...41 Figura 3.8 Pesquisa de estabelecimentos e sistema de compra on-line do Disk Cook (2008)...41 Figura 3.9 Diagrama de Contexto do Domínio de Catálogo de Estabelecimentos do Ramo Alimentício...46 Figura 3.10 Diagrama de Características Funcionais de Consultas...48 Figura 3.11 Diagrama de Características Conceituais e Funcionais do Cliente...50 Figura 3.12 Diagrama de Características Conceituais do Estabelecimento...51 Figura 3.13 Diagrama de Características Funcionais da Pessoa Física...54 Figura 3.14 Diagrama de Características Funcionais do Administrador...55 Figura 3.15 Diagrama de Características Conceituais do Pedido...56 Figura 3.16 Mapeamentos de Características Conceituais para o Modelo de Classes...57

Figura 3.17 Mapeamentos de Características Funcionais e de Entidade para o Modelo de Casos de Uso...59 Figura 4.1 Tela Inicial da Implementação do Catálogo de Estabelecimentos do Ramo Alimentício para Campos/RJ...61 Figura 4.2 Trecho de código PHP combinado com JavaScript e XHTML...63 Figura 4.3 Banco de Dados da Implementação do Catálogo de Estabelecimentos do Ramo Alimentício para Campos/RJ na Interface do phpmyadmin...64 Figura 4.4 Alerta Gerado Através de Código JavaScript após Validação de Campo Obrigatório...65 Figura 4.5 Mapeamentos de Características Funcionais e de Entidade do Catálogo de Estabelecimentos do Ramo Alimentício para Campos/RJ para o Modelo de Casos de Uso...67 Figura 4.6 Implementação do Caso de Uso Pesquisar Estabelecimento...68 Figura 4.7 Mapeamentos de Características Conceituais do Catálogo de Estabelecimentos do Ramo Alimentício para Campos/RJ para o Modelo de Classes...69

LISTA DE SIGLAS AD - Análise do Domínio DBC - Desenvolvimento Baseado em Componentes DSSA Domain Specific Software Architectures EA - Engenharia de Aplicação ED - Engenharia de Domínio FeatuRSEB - Reuse-Driven Software Engineering Business FODA - Feature Oriented Domain Analysis FORM - Feature Oriented Reuse Method HTTP - HiperText Transfer Protocol IMAP - Internet Message Access Protocol LP - Linha de Produtos de Software MDA Model-Driven-Architecture ODM - Organization Domain Modeling PHP - Hypertext Preprocessor PLUS - Product Line UML-Based Software Engineering POO - Programação Orientada a Objetos SEI - Software Engineering Institute SGBD - Sistema de Gerenciamento de Banco de Dados SMTP - Simple Mail Transfer Protocol UML Unified Modeling Language

SUMÁRIO LISTA DE FIGURAS E TABELAS...7 LISTA DE SIGLAS...9 CAPÍTULO 1: INTRODUÇÃO...12 1.1 MOTIVAÇÃO... 12 1.2 OBJETIVOS... 13 1.3 METODOLOGIA... 14 1.4 ORGANIZAÇÃO DA MONOGRAFIA... 14 CAPÍTULO 2: REFERENCIAL TEÓRICO...16 2.1 INTRODUÇÃO... 16 2.2 DOMÍNIO E ENGENHARIA DE DOMÍNIO... 17 2.2.1 Análise do Domínio... 20 2.2.1.1 Análise e Modelagem de Variabilidades... 21 2.2.1.2 O Modelo de Características e Notações para a Representação de Variabilidades... 22 2.2.1.3 A Notação Odyssey-FEX... 23 2.2.1.4 Ambiente de Suporte à Notação Odyssey-FEX... 27 2.2.2 Projeto do Domínio... 30 2.2.2.1 Frameworks... 31 2.2.2.2 Tipos de Frameworks... 32 2.2.3 Implementação do Domínio... 33 2.3 CONSIDERAÇÕES FINAIS... 34 CAPÍTULO 3: ESTUDO DE CASO NO DOMÍNIO DE CATÁLOGO DE ESTABELECIMENTOS DO RAMO ALIMENTÍCIO...35 3.1 INTRODUÇÃO... 35 3.2 ANÁLISE DE VIABILIDADE... 36 3.2.1 Trabalhos Relacionados... 36 3.2.2 Diagnóstico da Viabilidade do Domínio... 42 3.3 ANÁLISE DO DOMÍNIO... 43 3.3.1 Descrição do domínio... 44 3.3.2 Contextos... 45 3.3.3 Subdomínio de Ações do Usuário... 47 3.3.3.1 Características das Consultas... 48 3.3.4 Subdomínio de Ações do Cliente... 49 3.3.4.1 Características do Cliente... 49 3.3.5 Subdomínio de Ações do Estabelecimento... 50 3.3.5.1 Características do Estabelecimento... 51 3.3.5.2 Características dos Planos e Adicionais... 52 3.3.6 Subdomínio de Ações da Pessoa Física... 53 3.3.6.1 Características da Pessoa Física... 54 3.3.7 Subdomínio de Ações do Administrador... 54 3.3.7.1 Características dos Pedidos... 55 3.3.8 Mapeamento do Modelo de Características para o Modelo de Classes...56

3.3.9 Mapeamento do Modelo de Características para o Modelo de Casos de Uso...58 CAPÍTULO 4: IMPLEMENTAÇÃO DO DOMÍNIO DE CATÁLOGO DE ESTABELECIMENTOS DO RAMO ALIMENTÍCIO...60 4.1 INTRODUÇÃO... 60 4.2 TECNOLOGIAS UTILIZADAS... 61 4.2.1 Servidor Web Apache... 62 4.2.2 PHP 5... 62 4.2.3 Banco de Dados MySQL e phpmyadmin... 63 4.2.4 JAVASCRIPT... 65 4.3 IMPLEMENTAÇÃO DA APLICAÇÃO... 66 4.3.1 Instanciação do Domínio... 67 CAPÍTULO 5: CONCLUSÕES E TRABALHOS FUTUROS...71 5.1 CONCLUSÕES... 71 5.2 CONTRIBUIÇÕES E BENEFÍCIOS DO TRABALHO... 72 5.3 TRABALHOS FUTUROS... 72 REFERÊNCIAS...74 ANEXO A: MODELOS DE CLASSE E DE CASOS DE USO DO CATÁLOGO DE ESTABELECIMENTOS DO RAMO ALIMENTÍCIO...79 ANEXO B: DESCRIÇÃO DOS CASOS DE USO...82

CAPÍTULO 1: INTRODUÇÃO 1.1 MOTIVAÇÃO Devido à evolução tecnológica, softwares cada vez mais complexos podem ser desenvolvidos, agregando mais recursos e funcionalidades a fim de atender às necessidades da sociedade. Atualmente, há uma grande dependência desta sociedade com relação ao software para a realização da maior parte das tarefas do dia-a-dia, tais como compras no supermercado, transações bancárias, serviços governamentais, etc. A indústria de software ganhou destaque e se tornou fator determinante nas economias do mundo industrializado (PRESSMAN, 2001). Em conseqüência da enorme demanda do mercado, softwares têm de ser desenvolvidos em prazos curtos, com baixos custos e sem perder a qualidade para um atendimento eficiente ao cliente. Logo, o emprego de metodologias que apóiem este tipo de desenvolvimento se faz necessário. Neste contexto, a reutilização de software se apresenta, consistindo basicamente no processo de reutilização de artefatos já existentes na produção de novos sistemas de software (FRAKES e KANG, 2005). Desta forma, sabendo-se que estes artefatos já foram testados em outras situações, pressupõe-se que os mesmos apresentam uma qualidade já validada e verificada, assim, diminui-se o esforço aplicado em pesquisas acerca de um mesmo projeto, minimizando o custo do software e aumentando a sua qualidade. Por meio de estudos realizados na área, analisou-se que os ganhos obtidos com a reutilização de software poderiam ser mais vantajosos se esta fosse aplicada desde o início do seu ciclo de vida, não se detendo ao reuso de código, mas se aplicando também a outros artefatos de software, como especificação de requisitos e modelos de projeto. Abordagens de Engenharia de Domínio (ED) e de Linhas de Produtos (LP) possuem este foco. A Engenharia de Domínio é uma das técnicas possíveis para aplicação da reutilização de software, ela trabalha na criação de soluções genéricas para que estas soluções venham a ser reutilizadas pelas aplicações do domínio (i.e. conjunto

13 de problemas reais que apresentam características em comum), tratando as suas variabilidades que são de suma importância para a análise do domínio, pois as mesmas ressaltam os pontos nos quais as aplicações do domínio se assemelham para serem posteriormente reutilizados e os pontos em que se diferem para um futuro estudo mais cauteloso durante a implementação. Outras técnicas também empregadas na reutilização de software são: métodos de desenvolvimento baseado em componentes (DBC), padrões de projetos, Frameworks, dentre outras. Os Frameworks serão apresentados neste trabalho juntamente com métodos e ferramentas de Engenharia de Domínio e Engenharia de Aplicação (EA). 1.2 OBJETIVOS Diante do exposto, o objetivo desse trabalho é abordar o desenvolvimento de software voltado à reutilização, discutindo algumas das técnicas baseadas em reutilização, como Engenharia de Domínio e uma de suas etapas, a Análise do Domínio (AD), Frameworks e Engenharia de Aplicação. Para este estudo foi escolhido o domínio de Catálogo de Estabelecimentos do Ramo Alimentício, já que o mesmo apresenta características que nos remetem a implementação de um framework por ser um tipo de sistema com grande procura atualmente no mercado, e a uma análise de domínio tendo em vista que este deve ser flexível e adaptável para cada aplicação específica. Pretende-se assim, vivenciar a experiência no desenvolvimento para a reutilização visando à concretização do conhecimento adquirido. Objetiva-se ainda apresentar um ambiente de modelagem baseado em reutilização (Odyssey) e uma notação para a modelagem de variabilidades (Odyssey-FEX), possibilitando através destes a construção de um framework para o referido domínio. A linguagem utilizada para a implementação do domínio será o PHP (Hypertext Preprocessor), no entanto, é importante destacar que a base da modelagem é independente da linguagem utilizada, ou seja, o projeto pode ser implementado em qualquer linguagem de programação desejada desde que esta seja orientada a objetos. Entretanto, o principal objetivo desse trabalho é colaborar

14 para estudos futuros, desenvolvendo a base do sistema para reutilização, deixando assim o framework pronto para ser instanciado para diferentes aplicações da família deste domínio por diferentes empresas. 1.3 METODOLOGIA A proposta deste trabalho é a realização da análise e estudo de técnicas de reutilização de software, tais como Engenharia de Domínio, Frameworks e Engenharia de Aplicação, e de uma pesquisa acerca do domínio de Catálogo de Estabelecimentos do Ramo Alimentício através de sites na web referentes a esta área de negócio, recolhendo as principais informações sobre os serviços oferecidos. Dessa forma, pretende-se realizar uma análise da viabilidade deste domínio, para posteriormente tornar possível o desenvolvimento de um framework que atenda às necessidades ainda existentes no mercado em relação a este domínio. Espera-se ainda, que através dos estudos propostos sejam apresentados os ganhos obtidos e a viabilidade de um desenvolvimento voltado para reutilização. 1.4 ORGANIZAÇÃO DA MONOGRAFIA Esta monografia contempla mais quatro capítulos a partir desta Introdução. No capítulo dois, é exposto o referencial teórico utilizado no presente trabalho em detalhes, no qual exploram-se os conceitos da Engenharia de Domínio e suas etapas, tais como a Análise do Domínio e o Projeto do Domínio com enfoque nos Frameworks. Ainda são abordados conceitos de reutilização de software e de modelagem de variabilidades em um ambiente desenvolvido especificamente para este fim, o ambiente Odyssey (ODYSSEY, 2008) e sua notação Odyssey-FEX. No capítulo três, as técnicas e conceitos de reutilização apresentados no capítulo dois são empregados na elaboração do modelo de domínio e no mapeamento de características para o domínio de Catálogo de Estabelecimentos do Ramo Alimentício, sendo este dividido em subdomínios. Este estudo de caso ainda

15 conta com uma Análise de Viabilidade do domínio a partir da pesquisa de trabalhos a este relacionados. No capítulo quatro, descreve-se a implementação do domínio de Catálogo de Estabelecimentos do Ramo Alimentício analisado previamente no capítulo 3, as tecnologias utilizadas no desenvolvimento: PHP (Hypertext Preprocessor), JavaScript, banco de dados MySQL e o gerenciador de banco de dados phpmyadmin, bem como as técnicas de Engenharia de Aplicação para a instanciação do domínio. No capítulo cinco, são apresentadas as conclusões obtidas no decorrer da realização deste trabalho, destacando a importância de um desenvolvimento voltado para reutilização e seus benefícios. São exploradas também as possibilidades para trabalhos futuros, além dos benefícios adquiridos e das contribuições para projetos e estudos posteriores. Por fim, em anexo são ilustrados os modelos de casos de uso e de classes do domínio de Catálogo de Estabelecimentos do Ramo Alimentício no Anexo A, seguidos pelas descrições de seus casos de uso no Anexo B.

CAPÍTULO 2: REFERENCIAL TEÓRICO 2.1 INTRODUÇÃO Em virtude da grande demanda da indústria e dos altos níveis de complexidade que o software vem adquirindo com o decorrer do tempo, atualmente, são realizados muitos estudos na área de Engenharia de Software com objetivo de aumentar a produtividade e a qualidade a fim de atender às exigências da indústria. Desse modo, a reutilização de software é uma atividade que tem sido amplamente difundida na comunidade de desenvolvimento de software, por se tratar de uma das poucas abordagens concretas que visa solucionar este problema. O reuso de software é definido por Prieto-Diaz (1989) como o uso de conceitos ou produtos previamente adquiridos ou construídos em uma nova situação, englobando todo um processo de representação desses produtos em vários níveis de abstração, o seu armazenamento para referências posteriores, a comparação entre situações novas e antigas com objetivo de identificar similaridades, a recuperação total ou parcial de produtos já desenvolvidos e sua adaptação à nova situação. O reuso de software surgiu da observação de que os softwares geralmente seguem padrões semelhantes, sendo possível explorá-los e assim, aplicar menos esforços em soluções para problemas já resolvidos anteriormente (MEYER, 2000). A reutilização não está limitada a fragmentos de código fonte. Todo o trabalho gerado durante o processo de desenvolvimento de software, como dados, requisitos, arquitetura e projeto são artefatos que podem ser reutilizados no futuro (MELO, 2004). O uso de técnicas de reutilização desde as primeiras fases do ciclo de vida do software dá suporte a reutilização de componentes em fases mais avançadas do desenvolvimento (ODYSSEY, 2008). Neste sentido, a Engenharia de Domínio em conjunto com os frameworks visam à produção de um modelo de domínio reutilizável para uma família de aplicações com características similares. Este modelo poderá ser recortado a fim de desenvolver aplicações específicas para este domínio, possibilitando-se, assim, uma grande vantagem do reuso de artefatos de análise e

17 de projeto. Os frameworks, neste contexto, podem ser vistos como arquiteturas específicas de domínio. Na seção seguinte deste capítulo, serão abordados os conceitos principais envolvidos na Engenharia de Domínio e seu desenvolvimento. 2.2 DOMÍNIO E ENGENHARIA DE DOMÍNIO Na Engenharia de Software, o termo domínio é utilizado para referenciar um conjunto de aplicações ou problemas reais que possuam características em comum (PRIETO-DIAZ e FREEMAN, 1987). Nesse sentido, a Engenharia de Domínio é o processo no qual é identificado o domínio do problema, a fim de descrever e definir a sua solução (PRIETO-DIAZ e ARANGO, 1991). Segundo Pressman (2001), o objetivo da ED é identificar, construir, catalogar e disseminar um conjunto de componentes de software com possibilidades de aplicabilidade em um software existente ou futuro, em um domínio de aplicação particular. Na ED, as características semelhantes e as diferenças (variabilidades) de um determinado domínio são agrupadas e representadas em um modelo genérico, denominado Modelo de Domínio, para a produção de artefatos de software reutilizáveis. Esses artefatos são catalogados e armazenados de forma que possam ser utilizados a qualquer momento por outra aplicação que se encontre no mesmo contexto do domínio (WERNER e BRAGA, 2005). Portanto, sistemas específicos podem ser gerados a partir de tais artefatos do domínio, instanciando-os de acordo com os requisitos da aplicação específica. Tal processo de reutilização de artefatos já existentes é denominado Engenharia de Aplicação (MILER, 2000). A EA e a ED trabalham em conjunto no intuito de prover a reutilização de tal forma que a ED é voltada à construção de um conjunto de artefatos que serão reutilizados, enquanto que a EA é responsável por implementar aplicações com base na instanciação dos artefatos construídos na ED, o que denota, respectivamente, o desenvolvimento para reutilização e o desenvolvimento com reutilização, conforme a Figura 2.1. Durante o processo da EA, pode surgir a necessidade de se

18 produzir novos artefatos para o domínio, ou adaptar artefatos existentes, fornecendo um feedback para a ED (OLIVEIRA, 2006). Figura 2.1 Ciclo de Vida da Engenharia de Domínio (OLIVEIRA, 2006) Para que o software alcance sucesso, a ED deve ser aplicada desde o início do seu ciclo de vida, produzindo artefatos ao mesmo tempo específicos para o domínio em questão e genéricos o suficiente para satisfazer toda a variedade de aplicações possíveis àquele domínio. Outra técnica de reutilização é a Linha de Produtos de Software, que segundo o SEI (Software Engineering Institute, 2008) é definida como: Um conjunto de sistemas de software que compartilham um conjunto de características comuns e controladas, que satisfazem necessidades de um segmento de mercado em particular, e são desenvolvidos a partir de artefatos comuns, de forma predefinida. A LP representa uma vertente da ED cujo foco foi transferido para o âmbito empresarial, sendo criada uma linha de produtos a partir de um conjunto de softwares similares existentes em uma empresa. As técnicas de ED e LP possuem muitas semelhanças, principalmente no desenvolvimento de uma família de sistemas como abordagem de reutilização. Ambas incorporam uma atividade de análise dos aspectos comuns e diferentes entre

19 os sistemas, porém cada técnica tem sua forma de tratar o desenvolvimento dessa família de sistemas. Uma diferença que pode ser observada entre estas abordagens é a maneira pela qual ocorre a definição de escopo, i.e., a abrangência dos elementos que serão reutilizados. Enquanto a ED parte de fontes como especialistas ou livros para organizar o conhecimento do domínio e obter os pontos passíveis de reutilização, a LP determina seu escopo a partir de produtos pré-determinados, i.e., produtos previamente escolhidos para fazer parte da LP e, por meio destes, as características comuns e variáveis entre eles são abstraídas e generalizadas, de forma a fazerem parte do núcleo de artefatos que serão reutilizados (OLIVEIRA, 2006). A Figura 2.2 apresenta as fases ou macro-atividades do processo da Engenharia de Domínio. Figura 2.2 Fases da Engenharia de Domínio (RADÜNZ, 2007) A partir do levantamento da documentação existente sobre o domínio, é realizada uma Análise de Viabilidade, na qual o mercado do domínio é estudado, verificando a existência de clientes e possíveis concorrentes, levando em consideração se há potencial econômico para dar continuidade ao projeto. Deve-se, então, verificar a maturidade do domínio em questão, ou seja, se a documentação existente sobre o domínio é suficiente para o seu estudo e a extração dos seus

20 conceitos, e se os requisitos em comum são estáveis para justificar o desenvolvimento para reutilização. Com base nessas informações, estima-se o esforço e recursos necessários à implementação e o período previsto para retorno do investimento, sendo possível diagnosticar a viabilidade do domínio. Por fim, após a conclusão do estudo de viabilidade, a Análise do Domínio deve ser iniciada com o objetivo de identificar suas características comuns e variáveis. A partir desta análise são estabelecidos o modelo de características (do inglês, features) e o glossário do domínio (Figura 2.2). As seções subseqüentes descrevem em maiores detalhes as etapas de Análise do Domínio e Projeto do Domínio. 2.2.1 Análise do Domínio A Análise do Domínio é a base para uma abordagem de ED de sucesso. É nessa etapa em que são identificados o domínio, o seu escopo e as características comuns e variáveis para esta família de aplicações (OLIVEIRA, 2006). Uma característica pode ser definida como um aspecto, uma qualidade, ou uma característica visível ao usuário, proeminente ou distinta, de um sistema (ou sistemas) de software (KANG et al., 1990). O processo da AD envolve aprendizado, existindo uma preocupação por capturar, coletar, organizar e modelar o conhecimento dentro de um determinado domínio de interesse (PRIETO-DIAZ e ARANGO, 1991). Um primeiro aspecto a ser considerado na AD é o escopo do domínio. Ele deve ser delimitado de acordo com o objetivo estabelecido para que a análise não se torne uma tarefa complexa e interminável, sem, no entanto, perder sua abrangência para que os artefatos possam ser gerados para atender as aplicações dentro do domínio. Após a definição do escopo do domínio, os pontos que possuem aspectos comuns e os pontos que possuem aspectos diferentes no domínio devem ser verificados e tratados. Essa atividade de identificação das variabilidades do domínio é um dos principais objetivos da AD e será melhor abordada na seção Análise e Modelagem de Variabilidades.

21 Pressman (2001) descreve um processo genérico para a realização da AD com as seguintes etapas: 1) Definir o domínio a ser investigado: para que seja possível aplicar a ED a um projeto de software é preciso que sejam definidos o domínio de atuação do software e o seu escopo; 2) Categorizar os itens extraídos do domínio: após a definição do domínio, as suas características são extraídas e agrupadas para melhor entendimento; 3) Coletar uma amostra representativa das aplicações do domínio: verifica-se, caso possua, aplicações existentes referentes ao domínio, para que elas possam ser analisadas, auxiliando na descoberta de outras características do domínio; 4) Analisar cada aplicação da amostra: analisar as aplicações, visando o domínio de uma forma geral, identificando os pontos de variação existentes, i.e. as características específicas a cada aplicação, e as características em comum; 5) Desenvolver um modelo de análise para as características extraídas: depois de coletar todos os dados necessários, deve-se gerar um modelo de domínio coerente. E ainda, existem outras fontes de informação sobre o domínio para investigação, tais como: livros, documentos, sites na Internet, usuários e especialistas do domínio. 2.2.1.1 Análise e Modelagem de Variabilidades A variabilidade é um conceito chave na ED, e consiste em tratar as semelhanças e as diferenças em um determinado domínio, i.e., características do domínio, classificando-as como ponto de variação, variantes e invariantes. Segundo Vasconcelos et al. (2007), um ponto de variação reflete a parametrização no domínio de uma maneira abstrata e deve ser configurável através de suas variantes. A identificação dos pontos de variação, juntamente com suas variantes possibilita construir um modelo de fácil entendimento com uma alta capacidade de

22 adaptação/extensão ampliando seu potencial de reutilização futura (OLIVEIRA, 2006). Bosch (2004) define o termo variabilidade como a capacidade que um sistema ou artefato de software tem de ser alterado, customizado, ou configurado para uma situação em particular. Ou seja, de acordo com um domínio, o mesmo artefato pode ser configurado de formas diferentes para a aplicação A e para a aplicação B, de acordo com as necessidades de cada uma. Na seção a seguir, serão mencionadas algumas notações para a representação de variabilidades, baseadas no modelo de características. 2.2.1.2 O Modelo de Características e Notações para a Representação de Variabilidades Segundo Blois (2006), o Modelo de Características (Features Model) é o mais conhecido entre os modelos de domínio, sendo considerado o melhor caminho para realizar o recorte do domínio para a construção de uma aplicação, por ser um elemento chave para relacionar os conceitos de mais alto nível aos demais artefatos de análise e projeto do domínio. Alguns métodos de ED propõem notações para a modelagem das variabilidades, baseadas no Modelo de Características, como por exemplo, o FODA (Feature Oriented Domain Analysis) (KANG et al., 1990), que de acordo com Oliveira (2006), é o precursor das notações baseadas em modelos de características. Além do FODA, existem outros métodos como o FORM (Feature Oriented Reuse Method) (KANG et al., 2002), que é uma extensão do método FODA, FeatuRSEB (Reuse- Driven Software Engineering Business) (GRISS et al., 1998), ODM (Organization Domain Modeling) (SIMOS e ANTHONY,1998), PLUS (Product Line UML-Based Software Engineering) (GOMAA, 2004), CZARNECKI (CZARNECKI, 2004, 2005), Odyssey-DE (BRAGA, 2000) e CBD-Arch-DE (BLOIS, 2006). O método CBD-Arch- DE é suportado pelo ambiente de reutilização Odyssey da COPPE/UFRJ (ODYSSEY, 2008) e utiliza a notação Odyssey-FEX, que é adotada neste trabalho. O ambiente Odyssey e a notação Odyssey-FEX serão apresentados nas próximas seções.

23 Há também outros métodos que modelam as variabilidades utilizando a própria UML e definindo estereótipos para representar as variabilidades, como os trabalhos de Clauss (2001) e de Morisio (et al., 2000), e o modelo proposto por Winck (2005) de extensão da UML para a modelagem de variabilidade transversal em componentes. 2.2.1.3 A Notação Odyssey-FEX A notação Odyssey-FEX permite a classificação das características de acordo com a sua categoria, opcionalidade e variabilidade (OLIVEIRA, 2006). A classificação das características de acordo com a sua categoria é descrita na Tabela 2.1 a seguir. Ícone Tipo de Característica Características de Domínio Características intimamente ligadas à essência do domínio. Representam as funcionalidades e/ou os conceitos do modelo e correspondem a casos de uso e componentes estruturais concretos. Características de Entidade São os atores do modelo. Entidades do mundo real que atuam sobre o domínio. Podem, por exemplo, expor a necessidade de uma interface com o usuário ou de procedimentos de controle. Características de Ambiente Operacional - Características que representam atributos de um ambiente que uma aplicação do domínio pode usar e operar. Ex: tipo de terminal, sistemas operacionais, bibliotecas etc. Características de Tecnologia de Domínio - Características que representam tecnologias utilizadas para modelar ou implementar questões específicas de um domínio. Ex: métodos de navegação em um domínio de aviões. Características de Técnicas de Implementação Características que representam tecnologias utilizadas para implementar outras características, podendo ser compartilhadas por diversos domínios. Ex: técnicas de sincronização. Tabela 2.1 Tipos de Características na notação Odyssey-FEX (OLIVEIRA, 2006) Características de Características de Projeto Análise (Tecnológicas)

24 Segundo Oliveira (2006), as características de Entidade são mapeadas para atores e características de Domínio devem ser mapeadas para os demais artefatos da AD, como casos de uso e classes em alto nível, ao passo que as características Tecnológicas devem ser mapeadas para artefatos da fase de projeto do domínio. As características de domínio podem ser funcionais, ou seja, que fazem referência aos casos de uso ou aos métodos; ou conceituais, que são ligadas às classes ou atributos do domínio. Como já foi exposto anteriormente, as características também podem ser classificadas de acordo com a sua opcionalidade e variabilidade. A classificação destas características quanto a opcionalidade determina se a característica é obrigatória ou não. As características podem então ser mandatórias quando são necessárias para qualquer aplicação do domínio, ou opcionais quando não é necessária em pelo menos uma das aplicações instanciadas a partir do domínio que a deu origem. Segundo sua variabilidade, as características nesta notação também podem ser classificadas como pontos de variação, variantes ou invariantes. Segue na Tabela 2.2 a descrição dessas propriedades por Oliveira (2006). Característica Pontos de Variação Variantes Invariantes Definição Determinados pontos em um sistema de software onde decisões são tomadas a respeito, por exemplo, de qual variante será utilizada. Em outras palavras, pontos de variação refletem a parametrização no domínio de uma maneira abstrata e são configuráveis através das variantes. De acordo com a descrição encontrada em (SCHMID, 1997), que considera o uso de frameworks como técnica de reutilização de software, os pontos de variação dão origem aos hot-spots no Projeto do Domínio. Tais hot-spots podem ter diferentes alternativas de configuração, que distinguem as aplicações que serão construídas a partir do framework. Alternativas de implementação disponíveis para um ponto de variação são denominados Variantes. Em outras palavras, são elementos necessariamente ligados a um ponto de variação, que atuam como alternativas para se configurar aquele ponto de variação. Os elementos fixos, que não são configuráveis no domínio. Considerando o uso de frameworks como técnica de Projeto de Domínio, tais elementos invariantes são denominados frozen-spots (SCHMID, 1997). Tabela 2.2 Tipos de Características no ambiente Odyssey (OLIVEIRA, 2006)

25 Em um modelo de características, dentro da notação Odyssey-FEX, a semântica dos relacionamentos é valorizada, proporcionando uma melhor capacidade de representação e expressão do domínio (OMG, 2005). Essa incorporação à modelagem de característica foi proposta anteriormente por Miler (2000) e foram mantidas na notação Odyssey-FEX. A Tabela 2.3 adaptada de Miler (2000) descreve esses relacionamentos.. Representação Descrição Composição Relacionamento em que uma característica é composta de várias outras. Denota relação na qual uma característica é parte fundamental de outra, de forma que a primeira não existe sem a segunda. Agregação Relacionamento em que uma característica representa o todo, e as outras as partes. Similar à composição, porém as características envolvidas existem independentemente uma da outra. Herança Relacionamento em que há uma generalização/especialização das características. Este tipo de relacionamento indica que as características mais especializadas (filhas) herdam as peculiaridades de características mais generalizadas (antecessores). Associação Relacionamento simples entre duas características. Denota algum tipo de ligação entre seus membros. Pode ser nomeada, indicando um tipo específico de ligação. Alternativo (Alternative) - Relacionamento entre um ponto de variação e suas variantes, denota a pertinência de uma variante a um determinado ponto de variação. Implementado por (Implemented By) - Relacionamento entre Características de Domínio e Características Tecnológicas, ou entre Características Tecnológicas que se encontrem em camadas diferentes. Indicam que uma determinada tecnologia é utilizada para implementar a característica relacionada. Ligação de Comunicação (Communication Link) - Relacionamento existente entre Características de Entidade e Características de Domínio. Cumpre o mesmo papel do relacionamento de associação entre atores e casos de uso na UML Tabela 2.3 Tipos de Relacionamentos no ambiente Odyssey (MILER, 2000)

26 A Figura 2.3 mostra um exemplo de modelo de características na notação Odyssey-FEX referente a uma parte de um software para celular no ambiente Odyssey. Figura 2.3 Modelo de características da notação Odyssey-FEX (WERNER, 2008) Na Figura 2.3, o ator Usuário representa uma Característica de Entidade, ou seja, um usuário do domínio. Emitir Alerta vibratório representa uma Característica de Domínio funcional que dará origem a casos de uso ou métodos/operações do domínio. Enquanto, Telefone Celular, Agenda, Campainha, Jogos, Snake, Car Racer e Alarme, são Características de Domínio conceituais que darão origem às classes e atributos no domínio. Pode-se observar também exemplos de características mandatórias e opcionais de acordo com a notação Odyssey-FEX. Campainha, Agenda, Telefone Celular e Usuário são características mandatórias, evidenciadas pelo contorno contínuo. Enquanto Emitir Alerta Vibratório, Jogos, Snake, Car Racer e Alarme são opcionais, demonstradas pelo contorno tracejado. Nota-se diferentes tipos de relacionamento usados na Figura 2.3. A Ligação de Comunicação (Communication Link) ligando o Usuário ao Telefone Celular, o Alternativo (Alternative) usado para ligar Jogos, que é um ponto de variação, com

27 suas variantes Snake e Car Racer e por fim a Agregação ou Composição (relacionamentos todo-parte), ligando Emitir Alerta Vibratório, Agenda, Campainha, Jogos e Alarme ao Telefone Celular. Uma característica nessa notação pode possuir propriedades ortogonais de variabilidade e opcionalidade como demonstrado na Figura 2.4. Figura 2.4 Propriedades ortogonais da notação Odyssey-FEX (OLIVEIRA, 2006) 2.2.1.4 Ambiente de Suporte à Notação Odyssey-FEX Modelos desenvolvidos para um domínio de modo que estes possam ser reutilizados, assim como o desenvolvimento de qualquer outro software, precisam de atualização e manutenção, portanto devem ser desenvolvidos com o apoio de ambientes que permitam a sua contínua evolução. O Odyssey consiste em um protótipo acadêmico, desenvolvido pela equipe de reutilização da COPPE/UFRJ que suporta a notação Odyssey-FEX citada anteriormente. É um ambiente de desenvolvimento baseado em reutilização, disponível para utilização e desenvolvimento em nível nacional (ODYSSEY, 2008). O principal objetivo do Odyssey é fornecer para o desenvolvimento de software, mecanismos baseados em reutilização, servindo como uma estrutura na qual modelos conceituais, arquiteturas de software, e modelos implementacionais são especificados para domínios de aplicação previamente selecionados. Não foi encontrado um ambiente comercial com as funcionalidades para apoio à reutilização que o Odyssey oferece (BERNADETE et al., 2007), como por exemplo:

28 Desenvolvimento para reutilização, permitindo o desenvolvimento de modelos reutilizáveis de domínio através de processos de Engenharia de Domínio. Desenvolvimento com reutilização, por meio da Engenharia de Aplicação, possibilitando a instanciação de aplicações a partir dos modelos de domínio tornando possível fazer o recorte do mesmo, através da seleção e adaptação das características que devem fazer parte das aplicações, com exceção das características obrigatórias do domínio, que devem ser sempre selecionadas. Instanciação de padrões de projeto e arquiteturais em modelos de domínio e de aplicações. Engenharia reversa dinâmica e estática (VASCONCELOS, 2007). Ligações de rastreabilidade e mapeamentos entre modelos em diferentes níveis de abstração, possibilitando a reutilização dos diferentes modelos de domínio que devem compor as aplicações (BLOIS, 2006). Desenvolvimento orientado a modelos (i.e. MDA Model-Driven- Architecture), permitindo a geração de modelos de componentes específicos para uma plataforma a partir de modelos independentes de plataforma (MAIA, 2006). Na Figura 2.5 pode-se ver como é organizado o ambiente Odyssey. À esquerda, existe uma árvore na qual vários tipos de diagramas podem ser descritos, como, por exemplo, diagrama de características (features), casos de uso, tipos de negócio (business view), classes (structural view), componentes, etc. Ainda no exemplo da Figura 2.5, observa-se a lista de características (Features View), que é composta por features da tecnologia do domínio (ícone verde), features conceituais (ícones azuis), features funcionais (ícones amarelos), features de entidade ou atores (ícone branco).

29 Figura 2.5 Ambiente Odyssey Uma das funcionalidades presentes no Menu Tools dentro do ambiente Odyssey, é a (re)instantiation, que é usada para reinstanciar um processo previamente instanciado. Outra ferramenta presente no Menu Tools é o Backtracking, que é utilizada para engenharia reversa. Ainda no Menu Tools podese trabalhar com um desenvolvimento baseado em componentes, sendo estes, Componentes de Negócio (Business Components), Componentes Utilitários (Utility Components) e Componentes de Infra-Estrutura (Infrastructure Components). O ambiente Odyssey possui funcionalidades para suportar a ED e a EA, além de funcionalidades disponíveis na forma de plugins, cujo download pode ser feito através do próprio Odyssey sob demanda, como por exemplo o Odyssey-Metrics e o Odyssey-Tracer. Por conta dessas funcionalidades oferecidas, o ambiente Odyssey é escolhido para o desenvolvimento deste trabalho, dando suporte ao processo de Engenharia de Domínio e à construção de um framework para o domínio.

30 2.2.2 Projeto do Domínio Após a fase de Análise do Domínio, na qual os conceitos do domínio são extraídos e catalogados gerando o Modelo do Domínio, é iniciado o Projeto do Domínio. Nesta etapa deve-se definir a arquitetura que será empregada para suportar a implementação do modelo. Baseada no conhecimento obtido na análise, esta arquitetura constituirá um framework, i.e. um conjunto de classes, que será utilizado na implementação do domínio. Dessa maneira os conceitos do domínio serão transformados em classes ou componentes reutilizáveis. O foco principal do Projeto do Domínio é a documentação de uma arquitetura específica para o domínio, entretanto que esta seja genérica o suficiente para atender todas as aplicações do domínio, suportando sua implementação. Para tal, são geradas as Arquiteturas de Software Específicas de Domínio (DSSAs Domain Specific Software Architectures). De acordo com o SEI (2008), uma DSSA é definida como: uma arquitetura baseada nos pontos em comum e nas variabilidades das aplicações de um domínio. Ela é um componente de projeto reutilizável capaz de prover uma base para outros componentes arquiteturais reusáveis e também de código fonte. Para Blois (2006), existe um consenso entre vários autores sobre os elementos principais do processo de criação de uma DSSA, estes são: um modelo de domínio, os requisitos de referência (requisitos funcionais e não-funcionais, do domínio), uma Arquitetura de Referência (a ser configurada e estendida durante o processo de instanciação de aplicações, representando um framework para o domínio) e um processo de desenvolvimento que apóie a Engenharia de Domínio como um todo.

31 2.2.2.1 Frameworks Conforme apresentado anteriormente, a reutilização de software é uma técnica cada vez mais utilizada pelos desenvolvedores de aplicação, pois através dela é possível diminuir o tempo e o esforço empregados no desenvolvimento, para se concentrar mais em requisitos e aspectos específicos do seu sistema. Com este objetivo, frameworks têm sido pesquisados e desenvolvidos a fim de fornecer soluções genéricas e reutilizáveis para os diversos tipos de problemas de projeto de software. A aplicação de frameworks contribui na composição de soluções eficazes, pois dão suporte às abstrações de mais alto nível na criação de componentes e estruturas reutilizáveis (CAMINADA et al., 2003). De acordo com Gamma et al. (1998), um framework pode ser definido como um conjunto de classes cooperativas que constituem a fase de projeto reutilizável de software, fornecendo uma orientação arquitetural, dividindo o projeto em classes abstratas e definindo suas responsabilidades e colaborações. É importante não confundir frameworks com bibliotecas de classes, pois estes apresentam conceitos bem distintos. Em uma biblioteca de classes, cada classe fornece um serviço único independente das demais, em oposição ao framework, no qual as classes colaboram entre si. Na Figura 2.6 pode-se observar esta e as demais diferenças entre uma biblioteca de classes e um framework. Figura 2.6 Diferença entre biblioteca de classes e framework (SAUVÉ, 2002)

32 Um framework tem por objetivo a reutilização de código em aplicações que façam parte de um mesmo domínio, sendo assim, não se deve criar um framework muito específico para abordar somente um determinado problema de uma aplicação em particular, mas sim visando um domínio como um todo (MOURA et al., 2006). Conforme abordado anteriormente, dentro de um domínio as características (conceituais e funcionais) podem ser classificadas de acordo com a sua opicionalidade e variabilidade. Em um framework estas características são mapeadas para frozen-spots (pontos fixos) ou hot-spots (pontos variáveis). As características comuns a todas as aplicações do domínio (i.e. mandatórias) e invariáveis originam os frozen-spots, e serão definidas de uma forma inalterável em todas as instanciações do framework, sendo representadas, por exemplo, através de classes concretas. Já as características variáveis nas aplicações do domínio (i.e. opcionais ou pontos de variação) geram os hot-spots, que descrevem partes específicas do framework para uma ou várias aplicações do domínio e devem ser estendidas ou adaptadas quando da instanciação ou reutilização do framewrok, sendo representadas através de classes e métodos abstratos, métodos de template e outros padrões de projeto do Gamma et al. (2000). 2.2.2.2 Tipos de Frameworks Um framework pode ser classificado de acordo com duas dimensões: onde o framework é usado e como o framework é usado (SAUVÉ, 2002). A classificação segundo a forma de reutilização (como) define como as particularidades da aplicação são introduzidas, podendo ser: Inheritance-focused: também conhecido como caixa branca (white box), o reuso ou instanciação acontece por herança ou extensão, o desenvolvedor deve conhecer como o framework funciona, para poder criar subclasses das classes abstratas existentes no framework; Composition-focused: também conhecido como caixa preta (black box), as instanciações e composições feitas determinam as particularidades da aplicação, o desenvolvedor combina as diversas classes concretas existentes no framework com as suas classes próprias para formar a

33 aplicação desejada. Requer do desenvolvedor um menor conhecimento dos detalhes da implementação do framework; Híbridos ou caixa cinza (gray box): compõe uma mistura dos outros dois tipos de frameworks, caixa branca e caixa preta, na qual o reuso pode acontecer por herança e composição simultaneamente. A outra forma de classificação depende de onde o framework é aplicado, tais como: Frameworks de Infra-estrutura: ampararam a infra-estrutura de sistemas em diferentes domínios de aplicação, oferecendo serviços como busca, interfaces gráficas, persistência, segurança, etc; Frameworks de Integração: são empregados para integrar aplicações e componentes distribuídos (ex: middleware, como Corba); Frameworks de Aplicação: são utilizados como base das atividades de negócio de grandes domínios de aplicação. Encapsula conhecimento (expertise) aplicável a uma vasta gama de aplicações. Resolve apenas uma fatia do problema da aplicação. 2.2.3 Implementação do Domínio A Implementação do Domínio acontece após a conclusão das fases da Engenharia de Domínio (Figura 2.1). O SEI (2008) descreve a Implementação do Domínio: Utilizando o conhecimento do domínio, levantado durante a análise do domínio, e a arquitetura desenvolvida durante o projeto do domínio, engenheiros de domínio adquirem e, onde necessário, criam recursos reutilizáveis que são catalogados em uma biblioteca de componentes para serem reutilizados pelos engenheiros de aplicação. A Implementação do Domínio pode envolver também a extração de artefatos de sistemas legados existentes do domínio e a busca de componentes em bibliotecas de software para o reaproveitamento na construção de novas aplicações do mesmo domínio.

34 2.3 CONSIDERAÇÕES FINAIS Para que os benefícios esperados através de uma prática de reutilização sejam obtidos, tais como o aumento de produtividade e qualidade, redução de custo e tempo de desenvolvimento do software, é necessário que a reutilização seja feita de maneira sistemática. De acordo com Werner e Braga (2005), para que a reutilização de software seja efetiva, esta deve ser sistematicamente aplicada em todas as fases do desenvolvimento, desde a análise até a implementação. Esta necessidade dá lugar às técnicas de reutilização, como a Engenharia de Domínio e Linha de Produtos de software. Tecnologias como Frameworks apóiam abordagens de ED e LP através do apoio à definição de uma arquitetura de referência para o domínio. Tanto na Engenharia de Domínio, quanto na Linha de Produtos, as semelhanças e diferenças existentes entre as aplicações de uma família devem ser identificadas e documentadas, estabelecendo-se uma atividade denominada modelagem de variabilidades (POULIN, 1997), que ocorre durante a análise do domínio. Assim, conceitos inerentes à modelagem de variabilidade devem ser formalizados, e representados de maneira coerente através de uma notação adequada para todos os artefatos envolvidos, especificando-se as semelhanças e diferenças de uma família de aplicações com requisitos em comum (i.e. domínio). Conclui-se que esta etapa de Análise do Domínio é essencial para uma abordagem de ED e LP de sucesso, requerendo atenção minuciosa, caso contrário podem ocorrer falhas na modelagem, reduzindo então o potencial de reutilização dos artefatos do domínio.

CAPÍTULO 3: ESTUDO DE CASO NO DOMÍNIO DE CATÁLOGO DE ESTABELECIMENTOS DO RAMO ALIMENTÍCIO 3.1 INTRODUÇÃO No decorrer do trabalho nota-se a necessidade de se fazer sistemas voltados para a reutilização, um novo paradigma na construção de sistemas de software, visando assim um aproveitamento mais satisfatório dos artefatos desenvolvidos. No capítulo anterior, foram apresentadas abordagens e técnicas para a elaboração de um sistema reutilizável, neste ponto do trabalho tais técnicas são aplicadas para o desenvolvimento do domínio do Catálogo de Estabelecimentos do Ramo Alimentício. Para um melhor suporte a este trabalho, a utilização de uma ferramenta ou ambiente de desenvolvimento que propicie um mapeamento de um domínio que poderá ser reaproveitado se faz necessária. Desse modo, para um bom entendimento das características do domínio o ambiente utilizado foi o Odyssey, conforme apresentado no capítulo dois (seção 2.2.1.4 Ambiente de Suporte à Notação Odyssey-FEX). Este nos leva a uma visão mais ampla das diversas facetas do domínio, ajudando a identificar e entender as particularidades do projeto. O Odyssey oferece suporte ao desenvolvimento para reutilização através de processos de Engenharia de Domínio, e suporte ao desenvolvimento com reutilização, através da Engenharia de Aplicação, onde os artefatos gerados para o domínio são reaproveitados e adaptados, quando necessário. Ele ainda permite a construção de uma estratégia durante todas as minúcias do processo, fornecendo assim métodos, ferramentas e procedimentos que são adequados para a especificação de modelos e aplicações de um domínio específico. Neste capítulo são apresentadas as análises de viabilidade e de domínio para o domínio Catálogo de Estabelecimentos do Ramo Alimentício, através de descrições textuais e modelos de software utilizando a notação Odyssey-FEX e a UML aplicadas pelo ambiente Odyssey.

36 3.2 ANÁLISE DE VIABILIDADE Existem ambientes, como páginas da web, que são voltados para os estabelecimentos que necessitam mostrar e vender seus produtos, no entanto esses em sua maioria têm a finalidade apenas da propaganda ou têm um serviço de compra limitado. A seguir são citados os principais dentre estes sites, escolhidos por possuírem algum serviço em diferencial, como exemplo para a pesquisa na qual foi baseado o domínio de Catálogo de Estabelecimentos do Ramo Alimentício, tratado neste trabalho. Eles serviram de fontes de informação para a Análise de Domínio posteriormente apresentada, justificando o escopo de domínio abordado, a sua viabilidade e a necessidade do desenvolvimento de um novo modelo de domínio mais abrangente. 3.2.1 Trabalhos Relacionados Alguns ambientes on-line são voltados somente para pesquisa e propaganda de estabelecimentos, como por exemplo, o Guia Bares (2008), que pode ser visualizado na Figura 3.1. Figura 3.1 Página inicial do estabelecimento, com as cidades disponíveis (GUIA BARES, 2008)

37 O Guia Bares (2008) disponibiliza aos estabelecimentos a oportunidade de fazer divulgação do mesmo ao público conectado a Internet. Ao adentrar o site, o usuário pode vislumbrar as opções de cidades cadastradas e, ao escolher uma delas, verá os estabelecimentos listados. Estes locais listados contam com os seguintes dados: nome fantasia, endereço, telefones para contato, foto do local e de seus principais pratos e atrativos. Sua pesquisa se limita apenas a algumas cidades do Espírito Santo e não oferece serviço de entrega de pedidos. A Figura 3.2 mostra como é feita a publicidade no Guia Bares (2008). Figura 3.2 Página que o site oferece de publicidade aos estabelecimentos cadastrados (GUIA BARES, 2008) Outro exemplo é o Guia dos Restaurantes (2008), que pode ser observado na Figura 3.3, e representa um trabalho bem mais estruturado do que o Guia Bares (2008), principalmente no que tange a organização, pois o site é dividido em seções em um menu que facilita a navegação ao usuário.

38 Figura 3.3 Página inicial do site do Guia dos Restaurantes (2008) Observa-se, logo ao entrar, uma janela interativa onde o usuário tem acesso aos planos de contrato Standard (feito para abrigar bares e restaurantes que tenham site na Internet) e Professional (para os que não têm site na Internet). No plano Professional o Guia dos Restaurantes (2008) oferece uma página para o estabelecimento, esta é feita baseada em um modelo que pode ser visualizado facilmente na Figura 3.4. E para os usuários que visitam o site, é oferecido um sistema de busca de tipos de comida diversificados em algumas das principais capitais do país. Essas buscas apenas retornam endereço e telefone dos locais, não realizando pedidos on-line. Figura 3.4 Opções de planos que o Guia dos Restaurantes (2008) disponibiliza

39 O RestauranteWeb (2008) é um trabalho que oferece serviço a uma rede de restaurantes. O estabelecimento que contrata o serviço pode, ou disponibilizar o cardápio em seu próprio site, ou no portal do RestauranteWeb (2008). O que torna o serviço do RestauranteWeb (2008) interessante é o fato de restaurantes que não possuem seus próprios sites receberem os pedidos pelo telefone através do administrador do site que monitora-os pela Internet. Seu atendimento se restringe às principais cidades dos estados de São Paulo, Minas Gerais, Rio de Janeiro e Goiás. Como mostrado na Figura 3.5, o site possui um interessante serviço de pontuação para os clientes web, assim o usuário vai recebendo pontos em cada pedido que podem ser trocados por brindes, levando assim a uma fidelidade entre o site e o cliente. Figura 3.5 Página inicial do site RestauranteWeb (2008) Um novo tipo de trabalho é o BondGarfo (2008), visualizado na Figura 3.6, que propicia aos restaurantes um ambiente prático para divulgação da casa e do seu cardápio. Ele também atende aos consumidores permitindo que obtenham as informações sobre os restaurantes de forma padronizada e façam seus pedidos em qualquer restaurante do sistema rapidamente. Os cardápios são mantidos pelos próprios restaurantes e o pagamento do serviço é feito no ato da entrega, porque

40 quem faz essa cobrança é o estabelecimento. Para fazer a inclusão de um restaurante no BondGarfo (2008), basta preencher um cadastro simples e aguardar a resposta do site juntamente com a senha de acesso ao setor administrativo. O site efetua os pedidos, entretanto não se responsabiliza pela entrega, já que essa responsabilidade compete ao restaurante que possui este serviço de entrega. Caso contrário, o estabelecimento apenas prepara o pedido para o cliente buscar. Figura 3.6 Página inicial do site BondGarfo (2008) Na Figura 3.7, mais um exemplo importante, o Disk Cook (2008), que fornece serviços apenas para as capitais do Rio de Janeiro e de São Paulo, possuindo um site com pesquisa interativa, que divide os estabelecimentos em tipos de cozinha. Exibe o cardápio do local e alguns pratos principais para que o usuário realize o seu pedido on-line, como demonstra a Figura 3.8.

41 Figura 3.7 Página inicial do site Disk Cook (2008) Figura 3.8 Pesquisa de estabelecimentos e sistema de compra on-line do Disk Cook (2008)

42 3.2.2 Diagnóstico da Viabilidade do Domínio Após os estudos de casos realizados, percebe-se que existe uma enorme necessidade de algumas empresas do ramo alimentício, sejam elas de grande ou de pequeno porte, em chegar até o cliente final. Dessa maneira, aprimorando vários conceitos já vistos, estes serviços foram unidos no domínio Catálogo de Estabelecimentos do Ramo Alimentício, que é um catálogo voltado para restaurantes, lanchonetes, bares, dentre outros, fornecendo vários planos de contrato, contemplando somente a propaganda ou também o serviço de compras online. Depois da pesquisa apresentada, algumas considerações podem ser feitas. Sites, como o implementado pelo Disk Cook (2008), mantêm uma ótima organização aliada a um bom sistema de pedidos, onde o cliente entra e tem uma ótima visão dos pratos e opções diversas. Mas o Disk Cook (2008), além de só atender às capitais de São Paulo e do Rio de Janeiro, ele só possui apenas uma forma de contrato que dá ao estabelecimento o direito de disponibilizar um cardápio onde podem ser feitos pedidos de compra. Já o diferencial do Catálogo de Estabelecimentos do Ramo Alimentício é que o mesmo possui três tipos de contrato, os quais são adequados à necessidade dos estabelecimentos. Estes contratos serão explicitados nas seções seguintes. Outros sistemas, como o Guia Bares (2008) e o Guia dos Restaurantes (2008), fazem um excelente serviço de propaganda, onde os estabelecimentos se cadastram para poder melhor mostrar seus pratos e divulgar o seu trabalho na Internet. Porém se limitam apenas a este serviço, não havendo a possibilidade de realização de compras on-line, conforme oferecido pelo Catálogo de Estabelecimentos do Ramo Alimentício. O RestauranteWeb (2008) oferece duas possibilidades aos estabelecimentos conveniados. Uma possibilidade é a do próprio RestauranteWeb (2008) desenvolver um site para o estabelecimento onde ele poderá disponibilizar seus pedidos, que serão monitorados pelo administrador do RestauranteWeb (2008). Outra possibilidade é um espaço menor criado dentro do próprio site RestauranteWeb (2008) onde os restaurantes poderão disponibilizar seu serviço de pedido, que será monitorado da mesma forma.

43 O Catálogo de Estabelecimentos do Ramo Alimentício trabalha de forma semelhante, havendo a possibilidade de ser criado um perfil personalizado que é gerenciado pelo administrador do sistema, ou ainda, do estabelecimento simplesmente dispor de um link próprio e à parte do sistema. O RestauranteWeb (2008) não disponibiliza entrega de pedidos, sendo esta feita pelo próprio estabelecimento, diferentemente o Catálogo de Estabelecimentos do Ramo Alimentício se responsabiliza pela entrega, entrando em contato com o estabelecimento e transmitindo o pedido realizado pelo cliente no sistema, o que facilita para os estabelecimentos que não possuem este serviço. Baseado em pesquisas bem organizadas, com diversas categorias de acordo com o gosto do usuário como, por exemplo, pesquisa por nome do estabelecimento, tipo de ambiente, tipo de cozinha e localidade, o Catálogo de Estabelecimento do Ramo Alimentício também disponibiliza uma variedade especial para as empresas que necessitam apenas de uma publicidade mais eficaz, pois dentro do Catálogo de Estabelecimentos do Ramo Alimentício há também espaço para a propaganda. Nele é divulgado o endereço da empresa, fotos de alguns de seus pratos, telefones para contato, etc. Finalizando, o Catálogo de Estabelecimentos do Ramo Alimentício veio para suprir as necessidades do mercado, proporcionando às empresas e aos usuários uma melhor comunicação. 3.3 ANÁLISE DO DOMÍNIO Nesta etapa de análise do domínio, o domínio Catálogo de Estabelecimentos do Ramo Alimentício é especificado. Ao analisar este domínio foi constatada a necessidade de dividi-lo em subdomínios devido à sua complexidade e amplitude. A decomposição do domínio em subdomínios ajuda a compreender o todo através de suas partes (MOURA et al., 2007). Para cada subdomínio são apresentadas suas características e relacionamentos, como também suas opcionalidades e variabilidades através de um modelo de características. A partir do modelo de características, modelos de classes e casos de uso são mapeados através de regras

44 da notação Odyssey-FEX. Este modelo de classes representará o framework para o domínio analisado. A seção a seguir descreve com maiores detalhes o domínio em questão. 3.3.1 Descrição do domínio A qualidade dos serviços web oferecidos tornou-se o elemento diferencial na escolha do usuário devido à popularização da Internet e o número cada vez mais crescente de sites. Diante da grande variedade de opções o usuário procura serviços que atendam às suas necessidades em um menor tempo possível. Diversos tipos de instituições, perante a essas dificuldades, adaptaram-se e passaram a oferecer serviços e produtos em sua versão web, enfrentando o desafio de prover qualidade em um mercado muito competitivo. A criação de um Catálogo de Estabelecimentos do Ramo Alimentício on-line é um diferencial para estes estabelecimentos, pois através da terceirização do desenvolvimento de páginas particulares para os estabelecimentos é possível obter maior visibilidade, requerendo um baixo investimento do mesmo. O catálogo on-line exerce um papel fundamental de canal de comunicação, levando o receptor à fonte desejada de forma mais prática e abrangente, atingindo um maior número de consumidores simultaneamente. O Catálogo de Estabelecimentos do Ramo Alimentício tem como objetivo principal reunir informações deste mercado em um único site, a fim de facilitar a localização destes dados pelos consumidores e de oferecer outros serviços que atendam às suas necessidades, tais como venda de produtos, solicitação de reservas, acesso a promoções e sugestões diferenciadas, escolha de restaurante por tipo de cozinha, ambiente e outros. O domínio de Catálogo de Estabelecimentos do Ramo Alimentício requer soluções configuráveis para atender às exigências de cada estabelecimento, apresentando requisitos em comum e requisitos variáveis de uma aplicação para outra, justificando a realização de uma Análise de Domínio. Por se tratar de um domínio extenso e com muitas funcionalidades optou-se por dividi-lo em subdomínios de acordo com os usuários do domínio, ou seja, os atores envolvidos

45 no sistema. Assim, as funcionalidades referentes a cada ator foram agrupadas gerando os seguintes subdomínios: Ações do Usuário: envolve as ações relacionadas ao usuário que não possui um cadastro no sistema, limitando-se a realização de consultas, tais como a pesquisa de estabelecimentos, produtos, receitas, sugestões do chef e promoções; Ações do Cliente: abrange as ações referentes ao cliente que possui um cadastro no sistema, podendo ser um estabelecimento ou uma pessoa física, e assim, efetuar o login no sistema e interagir por meio do envio de receitas e mensagens através do fale conosco ; Ações do Estabelecimento: engloba as ações específicas do estabelecimento, a saber: a realização e manutenção de cadastro e a contratação de adicionais tais como sugestões do chef e promoções; Ações da Pessoa Física: envolve as ações particulares da pessoa física, sendo estas a realização e manutenção do seu cadastro, a compra de produtos e a solicitação de reserva de estabelecimento; Ações do Administrador: compreende as ações efetuadas pelo administrador do sistema, tais como o monitoramento e exclusão de pedidos, o cadastro de receitas e o gerenciamento dos estabelecimentos (aprovar perfil e manter contratos de planos). No ambiente Odyssey, estes subdomínios serão mapeados e representados em diagramas através de contextos, como descreve a seção a seguir. 3.3.2 Contextos Com base no que foi apresentado anteriormente, o domínio Catálogo de Estabelecimentos do Ramo Alimentício está dividido nos subdomínios: Ações do Usuário, Ações do Cliente, Ações do Estabelecimento, Ações da Pessoa Física e Ações do Administrador. Estes subdomínios estão representados como contextos no ambiente Odyssey através de um diagrama de contextos, como mostra a Figura 3.9.

46 Figura 3.9 Diagrama de Contexto do Domínio de Catálogo de Estabelecimentos do Ramo Alimentício Podemos identificar neste diagrama as relações entre os subdomínios e seus respectivos atores, que na notação Odyssey-FEX são mapeados como entidades. O domínio Catálogo de Estabelecimentos do Ramo Alimentício envolve os seguintes atores: Administrador: Responsável pela administração do sistema e pelo gerenciamento de conteúdo do site. É papel do administrador dirigir o sistema de entregas de pedidos e entrar em contato com os estabelecimentos quando necessário; Usuário: Visitante do site que não possui um cadastro no sistema, mas deseja realizar consultas e obter informações a cerca dos estabelecimentos, produtos e serviços oferecidos; Cliente: Usuário que possui um cadastro no sistema podendo usufruir os serviços oferecidos. O cliente é classificado como um estabelecimento ou uma pessoa física de acordo com suas características e interesses nestes serviços; Estabelecimento: Empresa de pequeno, médio ou grande porte do ramo alimentício (bares, lanchonetes, restaurantes, etc.) que contrata