XX SEMINCO - SEMINÁRIO DE COMPUTAÇÃO { { SEMINCO SEMINÁRIO DE COMPUTAÇÃO ANAIS FURB - BLUMENAU - SC

Transcrição

1 XX SEMINCO - SEMINÁRIO DE COMPUTAÇÃO XX SEMINCO XBr yrj = mi yrj >n0 { { XBi yji SEMINÁRIO DE COMPUTAÇÃO ANAIS 22 a 23 de AGOSTO de 2011 FURB - BLUMENAU - SC

2 Anais do XX SEMINCO Seminário de Computação 22 e 23 de agosto de 2011 FURB - Campus I - Blumenau/SC Promoção Universidade Regional de Blumenau - FURB Centro de Ciências Exatas e Naturais - CCEN Departamento de Sistemas e Computação - DSC Centro Acadêmico Livre de Computação - CALCOMP Comissão Organizadora Prof. Everaldo Artur Grahl (Coordenador) Prof. Antonio Carlos Tavares Prof. Aurélio Faustino Hoppe Prof. Dalton Solano dos Reis Felipe Demarchi Luciana Pereira de Araújo Matheus Luan Krueger Vilmar Orsi

3 Ficha Catalográfica Elaborada pela Biblioteca da FURB Seminário de Computação (20.: 2011 : Blumenau, SC) Anais do XX SEMINCO / promoção Universidade Regional de Blumenau, Departamento de Sistemas e Computação; Everaldo Artur Grahl, Dalton Solano dos Reis (coordenadores). - Blumenau, O Departamento, p. : il. 1. Computação - Congressos. I. Grahl, Everaldo Artur; Reis, Dalton Solano dos. II. Universidade Regional de Blumenau. Departamento de Sistemas e Computação. III. Título. CDD 004 Universidade Regional de Blumenau Reitor Prof. Dr. João Natel Pollonio Machado Vice-Reitor Prof a. Griseldes Fredel Boos Diretor do Centro de Ciências Exatas e Naturais Prof. Dr. Geraldo Moretto Chefe do Departamento de Sistemas e Computação Prof. Antonio Carlos Tavares Coordenador do Colegiado do Curso de Ciências da Computação Prof. José Roque Voltolini da Silva Coordenador do Colegiado do Curso de Sistemas de Informação Prof. Wilson Pedro Carli

4 Apresentação A Universidade Regional de Blumenau - FURB, através do Departamento de Sistemas e Computação, realiza o XX SEMINCO - Seminário de Computação nos dias 22 e 23 de agosto de Este ano completando duas décadas de realizações. Este evento foi criado em 1992 através de um grupo de professores e alunos da FURB interessados em divulgar e disseminar a produção interna de trabalhos e pesquisas de computação. O evento foi crescendo e hoje já é uma referência nacional na área, auxiliando na divulgação e produção científica de várias instituições brasileiras. Este ano tivemos a submissão de 24 artigos, sendo que destes foram aprovados 8 artigos provenientes das seguintes instituições: CPqD, FURB, IPEV, UNIFEI, UNIRITTER, UNI- SUL, UNIVALI e UTFPR. Estes artigos contemplam as áreas de Engenharia de Software, Integração Hardware / Software, Inteligência Artificial e Sistemas de informação. Agradecemos a todos os envolvidos na organização do evento, bem como a Comissão de Avaliação Interinstitucional que avaliou os artigos submetidos à chamada de trabalhos. Comissão Organizadora Agradecimentos Centro de Ciências Exatas e Naturais - CCEN Centro de Comunicação e Marketing Contribuintes do Projeto Acredito Sociedade Brasileira de Computação - SBC

5 Comissão de Avaliação Interinstitucional Adilson Vahldick (UDESC) Adriana G. Alves (UNIVALI) Alexandre Cidral (UNIVILLE) Angelo Frozza (IFC ) Anita Fernandes (UNIVALI) Aurélio Hoppe (FURB) Dalton Solano dos Reis (FURB) Denio Duarte(UFFS) Everaldo A. Grahl (FURB) Fabiane Barreto Vavassori Benitti (UNIVALI) Fernando dos Santos (UDESC) Frank Siqueira (UFSC) Jomi Hübner (UFSC) Marcel Hugo (FURB) Marcello Thiry (UNIVALI) Marcos Eduardo Casa (UCS) Patricia Vilain (UFSC)

6 Engenharia de Software Artigos Selecionados Uma Proposta de Modelo Conceitual para Repositório de Artefatos de Software Visando Promover o Reuso Beatriz T. Borsoi, Eliane M. de B. Fávero, Rúbia E. O. Schultz Ascari, Adriana Ariati, Renato Silva Belazi 6 Análise Comparativa entre Groovy e Java, Aplicado no Desenvolvimento Web 18 Vandir Fernando Rezende, Marcel Hugo Integração Hardware / Software Desenvolvimento de um Protótipo para Ensaios de Calibração do Sistema de Dados Aéreos usando Técnicas de Processamento de Imagens Luiz Eduardo Guarino Vasconcelos, Nelson Paiva Oliveira Leite, Carlos Alberto Murari Pinheiro, Otávio Augusto Salgado Carpinteiro 31 Inteligência Artifical Extensão Swarm Intelligence para o Simulador Robocup Rescue 44 Alessandro A. Ostetto, Fernando dos Santos Utilização de Processamento Digital de Imagens e Redes Neurais Artificiais para Diagnosticar Doenças Fúngicas na Cultura do Tomate Felipe S.Vieira, Rafael Paz, Clavison M. Zapelini, Adriana S. Zanini, Eros Comunello, Anita M.R.Fernandes 56 Sistema Especialista para Indicação de Medicamentos Fitoterápicos 70 Leonardo Veronese Soletti, Sidnei Renato Silveira Sistemas de Informação Sistema Gerenciador de Regras de Negócio Aplicado à Gestão de Recursos de Telecom: Estudo de Caso Celly de Siqueira Martins, Mauricio Amorim da Silva, Sindo Vasquez Dias, André Lara Temple de Antonio Gestão da Informação em Biblioteca Universitária: uma Proposta Utilizando Regras de Associação na Disseminação das Informações de Novas Aquisições Bibliográficas Maciel F. da Silva, Cláudio Ratke 82 95

7 6 Uma Proposta de Modelo Conceitual para Repositório de Artefatos de Software Visando Promover o Reuso Beatriz T. Borsoi 1, Eliane M. de B. Fávero 1, Rúbia E. O. Schultz Ascari 1, Adriana Ariati 1, Renato Silva Belazi 1 1 GETIC Grupo de Estudos e Pesquisas em Tecnologias de Informação e Comunicação Universidade Tecnológica Federal do Paraná (UTFPR) - Campus Pato Branco Via do Conhecimento Pato Branco PR Brasil {beatriz,elianedb,rubia}@utfpr.edu.br; adrianaariati@hotmail.com;rbelazi@hotmail.com Resumo. O reuso de artefatos de software ainda é um desafio. Isso porque é necessário que os artefatos sejam desenvolvidos visando reuso e mudanças na cultura organizacional podem ser necessárias para essa prática. Esse trabalho propõe um modelo conceitual de repositório de artefatos (documentos, componentes e procedimentos) com o objetivo de facilitar sua recuperação e reuso. Esse modelo tem como base técnicas de classificação como vocabulário controlado, com classificação por palavras-chave, descrição textual e enumeração ou hierárquica. O modelo proposto é simples em relação à forma de uso dos métodos, mesmo visando recuperação otimizada em relação aos critérios de busca. 1. Introdução O conceito de reuso pode ser aplicado a todo o ciclo de vida de um software, pois como argumentou Justo (1996), não há razões teóricas que impossibilitem sua aplicação nas fases iniciais do desenvolvimento. Para esse autor, a especificação de requisitos é uma fase crucial no ciclo de vida de um sistema e aplicar reuso efetivo nessa fase tornaria possível construir sistemas que atendessem melhor os requisitos requeridos pelo usuário. A orientação a objetos está estreitamente vinculada ao reuso de código, inclusive pelo seu mecanismo de herança. O desenvolvimento baseado em componentes também está centrado no reuso de elementos de código. Porém há outros escopos para reuso, como padrões de projeto e experiências e conhecimento adquiridos com a realização de atividades do ciclo de vida de software. Os padrões de projeto, tendo como referência os vinte e três padrões propostos por Gamma et al. (1997), podem ser definidos como componentes conceituais reutilizáveis. Eles se aplicam à produção de código, mas o que é reutilizado são os conceitos envolvidos, ou mais especificamente a estrutura conceitual de um padrão que resolve um problema bem estabelecido. Basili, Caldiera e Rombach (1994), consideram que o reuso de produtos, processos e experiências representam uma maneira de solução possível para o problema de

8 7 desenvolver sistemas com qualidade alta e custo baixo. Esses autores definem uma fábrica de experiências na qual há o reuso de conhecimento produzido nas atividades relacionadas ao desenvolvimento de software. O reuso pode estar vinculado, também, aos resultados das atividades de análise e de projeto, como, por exemplo, especificações de requisitos, diagramas de casos de uso, de classes e de banco de dados. Esses documentos são reaproveitados no desenvolvimento de projetos que possuam requisitos iguais ou semelhantes. Este trabalho se refere a reuso em um escopo mais amplo, abrangendo todos os produtos resultantes no ciclo de vida de software. Esses produtos são denominados artefatos, e representam componentes de código (software), documentos gerados (como diagramas de classes, planos de testes, modelos para elaboração de documentos) e procedimentos (métodos, técnicas, orientações para realizar as atividades) que podem ser resultantes da experiência da realização das atividades. O desenvolvimento baseado em reuso requer tempo e esforço consideráveis para que bons resultados sejam obtidos, o que tem sido uma barreira para pequenas organizações [Shiva e Shala 2007]. Em função disso, este trabalho propõe a definição conceitual de um repositório para o armazenamento de artefatos como descritos neste texto, de maneira a otimizar a busca. Também é proposta uma maneira de recuperação dos artefatos, visando a localização dos artefatos que atendem plenamente os requisitos de busca e dos que atendem parcialmente a esses requisitos. Otimização se refere a localizar o artefato mais adequado, dentre os armazenados no repositório, para o interesse de busca e de acordo com os critérios informados. Este texto está organizado em seções. Esta é a primeira e apresenta a introdução com uma visão geral do assunto, o problema e a proposta de solução. Na Seção 2 estão conceitos de reuso, repositório e métodos de classificação e busca. A Seção 3 apresenta trabalhos relacionados. Na Seção 4 está a solução proposta. E na Seção 5 está a conclusão. 2. Reuso e Repositório de Artefatos Reuso está relacionado ao uso de conceitos ou produtos previamente adquiridos ou construídos em situações novas [Biggerstaff e Perlis 1989]. Sendo que estes devem ser definidos e/ou produzidos visando o seu reuso, estarem armazenados de forma a facilitar sua recuperação e prover a identificação de similaridades entre situações novas e antigas permitindo sua adaptação [Prieto-Diaz 1989]. Kotonya, Lock e Mariani (2011) fazem um apanhado histórico sobre reuso, destacando as primeiras associações com o tema, iniciando com o trabalho de McIlroy (1968) que sugeriu que a indústria de software deveria ser baseada em componentes reusáveis. Na sequência, Parnas (1976) propôs a noção de família de programas e Neighbours (1984) definiu os conceitos de domínio e análise de domínio. Essas ideias iniciaram a sistematização de engenharia de linha de produtos de software, que é tratada por Greenfield e Short (2004) como fábrica de software. Mais recentemente destacam-se os trabalhos de Frakes e Kang (2005) e Shiva e Shala (2007) que identificaram mudanças na forma de localizar artefatos em repositórios. A popularidade do reuso aumentou

9 8 recentemente devido à possibilidade de desenvolvimento distribuído de software [Shiva e Shala 2007] ocasionada, principalmente, pela globalização e pelo desenvolvimento compartilhado por empresas distintas. Embora o conceito de reuso seja usualmente aplicado na fase de implementação de um software com o objetivo de reutilizar trechos de código, qualquer item gerado no processo de desenvolvimento de software pode ser reusado. Dentre esses itens estão os documentos de modelagem do sistema e os resultados de experiências e do aprendizado na realização das atividades, incluindo procedimentos e maneiras de resolver problemas. A aplicação de reuso nas fases iniciais de desenvolvimento de software foram investigadas desde o início da década de 1990, como atestam as publicações de Grosz (1992), Maiden e Sutcliffe (1992) e Sutcliffe e Maiden (1994). Melo (2007) também afirma que a reutilização, ou reuso, não é só aplicável a fragmentos de código fonte, mas a todo o trabalho gerado durante o processo de desenvolvimento de software, como dados, arquitetura e projeto, resultando nos benefícios: aumento da produtividade; aumento da qualidade; redução dos custos; redução no tempo de entrega; padronização; interoperabilidade; previsibilidade, confiabilidade e redução de riscos. A esses benefícios Sommerville (2007) acrescenta: uso de padrões e obtenção de resultados positivos em termos de produtividade e qualidade do software, pelo reuso de experiências. Para que artefatos sejam armazenados visando facilitar a sua localização, a documentação dos mesmos deve definir as suas características de identificação, tais como nome, descrição, data de criação e observações. Essas informações podem ser tratadas como metadados por mecanismos de busca. O aspecto relevante está em como organizar esses dados e definir os atributos do artefato de maneira que seja possível localizar o artefato que melhor atende aos interesses do usuário representados pelos critérios de busca. A estrutura do repositório é um fator essencial para os resultados de busca. Mesmo que algoritmos de busca possam prover resultados com um esforço mínimo de estrutura e indexação, repositórios fracamente estruturados com indexação inadequada não terão um bom desempenho independentemente dos algoritmos de busca [Henninger 1997]. 2.1 Métodos de Classificação e Recuperação de Artefatos A recuperação efetiva de artefatos de software em repositórios é afetada fortemente pela combinação dos métodos de classificação adotados. Neste trabalho, o termo método se refere aos diversos esquemas e procedimentos de classificação apresentados na literatura e utilizados na classificação e recuperação de artefatos. Um esquema de classificação é um meio de produzir uma organização sistemática com base em um vocabulário, seja controlado ou não [Prieto-Diaz 1991]. Desta forma, um vocabulário controlado constitui-se dos termos utilizados para especificar artefatos, extraídos de um conjunto predefinido de atributos. Já em um vocabulário não-controlado, os termos são automaticamente extraídos a partir dos textos que descrevem um componente por linguagem natural [Salton 1983; Vanderlei 2006]. Sendo assim, um esquema de classificação pode se basear em um ou em ambos os tipos de vocabulários, podendo ser das

10 9 seguintes formas: classificação por palavras-chave, por enumeração e classificação em facetas, conforme apresentadas a seguir. De acordo com Vanderlei (2006), a classificação por enumeração é um esquema de classificação que se baseia na submissão de informações a uma estrutura hierárquica prédefinida e mutuamente exclusiva. Esse esquema apresenta inflexibilidade inerente e problemas em entender grandes hierarquias, já que a estrutura pré-definida das categorias apenas permite a introdução de novos elementos de forma sequencial. No método de classificação por palavras-chave, os artefatos de software podem ser classificados, tanto por palavras extraídas automaticamente de textos contidos nos próprios artefatos (vocabulário não-controlado) ou fornecidas pelo usuário que o está classificando (vocabulário controlado). Métodos de texto livre são simples para construir e recuperar, mas precisam de grande quantidade de texto disponível para uma boa precisão nas buscas, sendo melhor aplicáveis para domínios com extensa documentação, apesar da busca ser menos cara, pois não requer intervenção humana [Maarek e Smadja 1989; Frakes e Pole, 1994]. Contudo, Hall (1992) destaca a dificuldade inerente ao uso de vocabulário nãocontrolado no método por palavras-chave na pesquisa, pois nem sempre a pessoa que classificou o componente é a mesma que irá recuperá-lo, podendo tornar difícil a recuperação de componentes por pessoas que não possuam conhecimento específico. A classificação por facetas consiste em categorizar os artefatos pela síntese dos valores das facetas. Uma faceta pode ser vista como uma propriedade do componente que deve aceitar valores pré-definidos. Também pode ser vista como um par atributo-valor, onde há um atributo fixado pela faceta e vários valores associados. Em um repositório, os possíveis valores de cada faceta são relacionados por meio de um grafo conceitual que permite relacionar valores sinônimos ou conceitualmente semelhantes [Prieto-Diaz 1991; Vanderlei 2006]. Para Vanderlei (2006), essa associação permite localizar componentes que se aproximam conceitualmente do componente pretendido. Facetas são mais flexíveis, precisas e se enquadram melhor para repositórios em constante expansão, se comparadas com esquemas enumerativos em repositórios que armazenam componentes homogêneos. 3. Trabalhos Relacionados Os primeiros trabalhos voltados para busca e recuperação de artefatos de software reutilizáveis tiveram seu foco voltado para os métodos de classificação desses artefatos [Prieto-Diaz 1991; Podgurski e Pierce 1993; Frakes e Pole 1994]. Estudos mostraram que os métodos de classificação disponíveis até então, não apresentavam diferenças significativas entre si. Sendo assim, outros aspectos começaram a ser observados e requisitados, especialmente em relação à recuperação de artefatos. Destaca-se a proposta de Henninger (1994) para a combinação de métodos de classificação, que visam permitir ao usuário o refinamento de suas expressões de busca, a fim de obter melhores resultados, como a recuperação de artefatos próximos aos requisitados e não apenas os que se apresentassem exatamente iguais à consulta. Anos mais tarde, o mesmo autor propôs um repositório com índices automaticamente atualizados à medida que novas consultas eram realizadas, de forma a facilitar futuras consultas do mesmo artefato.

11 10 Desta forma, a partir dos estudos realizados sobre classificação e recuperação de artefatos de software, visando a sua reutilização, muitos trabalhos têm sido realizados propondo a mescla de vários métodos já consolidados, como a busca por palavras-chave (pré-definidas ou em texto livre); por enumeração ou hierárquica (entre categorias prédefinidas de classificação) ou baseada em facetas. Esta seção apresenta alguns trabalhos que utilizam esses métodos. a) Maarek, Berry e Kaiser (1991) utilizam o conceito de busca em texto livre, identificando palavras-chave que melhor representem o componente em questão. b) Henninger (1994) propôs o sistema CodeFinger, cuja recuperação é sustentada pela reformulação interativa de perguntas e por uma aproximação da recuperação usando uma rede neural, com um algoritmo capaz de recuperar os componentes de software relacionados a uma dada pergunta, feita por palavras-chave, frases ou afinidades lexicais. c) Redolfi et al. (2005) identificam um conjunto de funcionalidades para um repositório de componentes de software oferecer suporte às atividades de desenvolvimento baseado em componentes. E propõem um repositório que atende a essas funciolidades, incluindo busca e recuperação, controle de versão e gerenciamento de controle de versão. d) Garcia et al. (2006) propuseram um mecanismo denominado Maracatu que permite o reuso de componentes de software, por meio de buscas em repositórios de código-fonte de projetos, realizadas pela combinação de métodos de recuperação por palavras-chave e facetas. Os autores mostraram, por meio de experimentos, que a combinação dos esquemas de busca por palavras-chave com facetas apresenta taxa de recuperação e precisão melhores em relação aos esquemas utilizados separadamente. e) Vanderlei et al. (2007) combinam técnicas originais de busca por palavras-chave e facetas com folksonomia. O suporte à folksonomia permite aos desenvolvedores popular com tags os componentes do repositório para futuras consultas e compartilhamento com os demais usuários do sistema. O estudo indica que o uso de folksonomia permite maior aproximação da realidade do usuário, seja no cadastro de artefatos ou na sua recuperação. f) Petrov e Buchmann (2008) adotaram o uso de palavras-chave, permitindo uma melhor representação dos requisitos do componente. Para auxiliar o usuário na classificação e recuperação dos componentes, são apresentadas questões, cujas respostas serão as palavras-chave pré-definidas para ambas as situações. As palavras-chave poderiam também ser diretamente informadas pelo usuário, indicando atributos desejáveis e não desejáveis para o componente de software. g) Batista Junior e Domingues (2010) definiram um método que gera automaticamente uma Forma Gráfica de Representação (FGR) para descrições de componentes de software em linguagem natural ou por questões de usuários. A busca de componentes na biblioteca é suportada pela avaliação automática do casamento (matching) entre a FGR de uma questão do usuário e as FGRs das descrições dos componentes da biblioteca. A análise da questão é realizada com a extração das palavras-chave da questão. A partir dos trabalhos apresentados, é possível perceber que o foco das pesquisas está bastante voltado para a eficácia na recuperação de artefatos de software a partir de um repositório, de forma a tornar essa tarefa mais prática, flexível e efetiva quanto possível, retornando o artefato desejado de maneira rápida e precisa. Todos os trabalhos apresentados

12 11 referem-se ao armazenamento e recuperação de componentes de código, a fim de oferecer suporte ao desenvolvimento de softwares baseado em componentes, o que reforça a relevância desta proposta, que visa trabalhar com artefatos de software diversos. 4. Modelo Conceitual de Repositório de Artefatos Visando Reuso Esta seção apresenta a proposta de modelo conceitual para um repositório de artefatos e para a recuperação desses artefatos. Os artefatos armazenados são caracterizados por atributos e outras informações consideradas necessárias para descrevê-los com o objetivo de facilitar a sua recuperação e reuso. O modelo proposto utiliza métodos de classificação baseados em vocabulário controlado, como a classificação por palavras-chave, por descrição textual e por enumeração ou hierárquica. A busca dos artefatos é realizada por palavras-chave informadas ou pré-definidas nos atributos de identificação do artefato e na sua descrição (neste caso a busca é feita por palavras-chave em texto livre). O uso combinado de técnicas distintas visa prover uma forma de localizar, além dos artefatos que melhor atendem aos critérios de busca, os artefatos com características próximas a esses critérios. Henninger (1994) propôs uma forma de busca aproximada, mas especificamente para componentes de software. O uso de busca em texto livre não onera o custo de processamento para a recuperação de artefatos. Isso porque essa busca ocorre no atributo de descrição do artefato e será realizada a partir de palavras-chave ao invés de indexadas como resultado de busca em texto livre. Essas palavras podem ser escolhidas a partir de um cadastro prévio ou informadas pelo usuário no momento da busca. O uso de palavras-chave facilita a implementação de mecanismos de busca, mas pode dificultar o cadastramento de artefatos no repositório. Se o conjunto dessas palavras é restrito, o artefato pode não ficar bem caracterizado. E um conjunto muito amplo pode conter palavras distintas para um mesmo conceito (sinônimos) e dificultar a recuperação do artefato desejado ou que melhor atenda aos critérios de busca. Brito et al. (2009) citam que alguns sistemas de repositório de componentes adotam técnicas de indexação que geram automaticamente informações de representação dos componentes, mas, mesmo assim, os componentes são localizados por busca exaustiva na coleção de informações [Girardi e Ibrahim 1994]. Por exemplo, em abordagens baseadas em ontologias [Sivashanmugam et al. 2003] a inferência sobre a coleção de conceitos é bastante custosa [Ding et al. 2004]. Brito et al. (2009) ressaltam que sistemas que adotam métodos de recuperação clássicos, baseados na indexação de termos, se sobressaem em eficiência quando comparados aos sistemas que empregam mecanismos de inferência. Para minimizar os problemas decorrentes de uso de palavras-chave diferentes para cadastrar e buscar um mesmo artefato, na proposta deste trabalho são definidos critérios para a inserção e orientações para busca. Os critérios se referem às padronizações recomendadas e a existência de um dicionário de sinônimos para ser consultado quando da inserção do artefato. As orientações explicam o contexto e exemplificam o conteúdo de cada campo de cadastro do artefato. Além disso, sugere-se que a inserção seja cooperativa, ou seja, os dados de cadastro de um novo artefato são verificados por usuários distintos.

13 12 Ainda assim, para que o reuso seja efetivo o desenvolvimento de software deve estar inserido em um contexto de desenvolvimento de software para e com reuso. Para reuso, se refere a que artefatos são produzidos visando reuso e com reuso está relacionado ao desenvolvimento de software com base em artefatos existentes. Desta forma, deve haver integração entre as atividades de produção de software e de componentes e o armazenamento e a disponibilização dos artefatos para reuso. A Figura 1 expressa essa integração por meio de processos que se comunicam. Esses processos são representados em notação BPMN (Business Process Modeling Notation). Nessa notação, retângulo com cantos arredondados representa atividade ou subprocesso, círculo com borda delgada indica o início do processo e círculo com borda espessa o seu final. A interligação entre processos é representada por seta pontilhada direcionada e entre as atividades de um processo por seta com traço contínuo. Produção Software requisitos Produção Componente s componentes Armazenamento Componentes componentes Disponibilização (Repositório Artefatos) especificações experiências modelos experiências componentes modelos procedimentos experiências modelos procedimentos Figura 1. Processos para produção de software com e para reuso A Figura 1 representa que a fábrica de software possui um processo de implementação que é suportado por um processo de produção de componentes. O processo de implementação envia requisitos e especificações para o processo de produção de componentes e este os desenvolve com o auxílio de modelos e procedimentos provenientes do repositório. Os componentes produzidos são disponibilizados no repositório por meio de um processo de armazenamento. O processo de produção de software implementa software reusando componentes, modelos e procedimentos. O conhecimento gerado na realização das atividades (denominado por experiência) é documentado e armazenado no repositório e disponibilizado para reuso com o nome de procedimento. No processo de implementação, tanto os modelos quanto os componentes de software podem ser adaptados ao contexto do projeto em desenvolvimento. Para serem devidamente recuperados, os componentes precisar ser cadastrados. Redolfi et al. (2005) classificaram, com base em diversos autores, as informações sobre

14 13 componentes de software em sete grupos: identificação, uso, maturidade, documentação, tecnologia, alteração e controle de qualidade. Considerando esses grupos é apresentado o Quadro 1 com os grupos propostos neste trabalho para o armazenamento de artefatos. Grupo Identificação Descrição Acesso Qualidade Relacionamentos Item Identidade; Nome; Versão; Local de disponibilização. Descrição; Tipo (componente, documento, procedimento); Classificação (base em palavraschave); Requisitos para uso; Restrições; Histórico de alterações. Disponibilidade (público ou privado); Leitura/Escrita; Descrição da interface (se componente); Tecnologia (linguagem, ferramenta de desenvolvimento). Testes de qualidade realizados e respectivos resultados. Pode ser usado com; Composto por; Depende de; Projetos que o utilizam. Quadro 1. Agrupamentos de informações sobre artefatos Na Figura 2 está o modelo conceitual proposto para o repositório de artefatos tendo como base o Quadro 1. Essa figura contém um conjunto de conceitos relacionados que explicitam a estrutura e a organização do repositório. Figura 2. Visão geral do repositório de artefatos O repositório provê o armazenamento de componentes de código, documentos produzidos durante o ciclo de vida (ex. plano de testes, diagrama de casos de uso), modelos de documentos (padrões e orientações) e procedimentos (o conhecimento gerado com a realização de atividades). As palavras-chave são utilizadas para definir requisitos do artefato e restrições (requisitos que o artefato não atende), podendo ser principais e secundárias. A descrição é utilizada para complementar a classificação baseada em palavras-chave. As palavras-chave secundárias permitem localizar artefatos que não atendem os requisitos ou critérios de busca completamente, mas que se aproximam deles. Os relacionamentos definem as conexões entre os artefatos e eles são estabelecidos quando da sua inserção no repositório. Na inclusão de um artefato, o sistema faz uma busca

15 14 no repositório visando identificar artefatos que possam estar relacionados e os sugere ao usuário. Essas sugestões são realizadas após nome, descrição e palavras-chave do artefato terem sido informados. A busca é realizada nesses campos e na descrição dos artefatos já armazenados. O usuário valida essas sugestões efetivando os relacionamentos considerados adequados e pode inserir outros relacionamentos além dos sugeridos pelo sistema. Em uma busca, os relacionamentos vinculados a um artefato são indicados. O histórico de mudanças contém as alterações realizadas em um artefato e o seu tipo, que podem ser correção de defeitos ou melhoria. Correção de defeitos indica que todos os projetos que utilizam o referido artefato deveriam atualizá-lo. E melhorias podem agregar ou não funcionalidades e gerar ou não inconsistências em projetos que utilizam o referido artefato. O registro dos artefatos utilizados nos respectivos projetos é mantido para, por exemplo, informar os projetos cujos artefatos passaram por alterações de melhoria e de correção de erros. Na Figura 4 está representada a definição conceitual para a busca de artefatos no repositório. O usuário escolhe entre palavras-chave existentes ou informa as palavras desejadas utilizadas para buscas no texto da descrição do artefato e nos atributos que o categorizam. Figura 3. Visão geral da busca no repositório de artefatos Dependendo do tipo de artefato procurado é definida uma busca hierárquica a partir das palavras informadas. Os artefatos resultantes de uma busca são apresentados em classificação descendente ao atendimento dos critérios de busca. E juntamente com cada artefato são informados os artefatos relacionados. Os artefatos de acesso público podem ser localizados em buscas por qualquer usuário. Os artefatos de acesso privado são disponibilizados para o autor e para outros usuários ou grupos de usuários. Esse controle de acesso possibilita o uso do repositório por conjuntos de fábricas de software, como, por exemplo, uma incubadora de empresas ou as que pertençam a um arranjo produtivo local. E, também, para o desenvolvimento cooperativo ou distribuído de software. O modelo proposto não determina como obrigatório o preenchimento de todos os campos para cadastramento de artefatos. Isso torna o sistema flexível e facilita o seu uso,

16 15 inclusive por fábricas de software de pequeno porte, porque uma solução computacional mais simples pode ser implementada. Contudo, ressalta-se que para maior efetividade na busca é necessário que os artefatos estejam bem caracterizados, com informações consistentes e completas. 5. Conclusão Considerando o levantamento bibliográfico realizado, percebe-se que existe uma carência de repositórios voltados para o reuso de artefatos de software como definido neste trabalho, pois os repositórios existentes estão, normalmente, voltados para componentes de software. A proposta deste trabalho fundamenta-se na necessidade verificada em fábricas de software, principalmente as de pequeno porte, em reaproveitar conhecimento, experiências, documentos e componentes de forma a agilizar os processos executados durante o ciclo de vida do software. Um repositório e formas de busca como apresentados neste trabalho podem ser vistos como um diferencial competitivo para fábricas de software de pequeno porte, mas não deixando de ser uma solução eficaz para o reuso de artefatos de software. Elas podem estar organizadas de maneira a trabalhar cooperativamente e assim compartilhar artefatos. O modelo proposto é bastante flexível, não tornando obrigatório o preenchimento de todos os campos na inserção do artefato. Contudo, ressalta-se que quanto melhor e mais completas estiverem as informações, mais eficiente e precisa será a busca. Desta forma, são definidas orientações de como inserir os artefatos, sendo que a inserção deve ocorrer com a verificação e validação por pessoas distintas. A forma de classificação e recuperação apresentadas pode representar uma solução para otimizar o reuso efetivo em repositórios de artefatos. Contudo, para afirmar os possíveis benefícios obtidos está sendo implementado um protótipo de software com a estrutura proposta neste trabalho, para então avaliar, na prática, junto a fábricas de software diversas, sua efetividade. Referências Basili, V., Caldiera, G. and Rombach, D. (1994) Experience Factory. In: J. Marciniak, Editor, Encyclopedia of Software Engineering, Wiley, p Batista Junior, J. and Domingues, P. E. (2010) Method for searching software components. In: Natural Language. IEEE Latin America Transactions, vol. 8, no. 3, June 2010, p Biggerstaff, T and Perlis, A. (1989) Classification of Reusable Modules, in Software Reusability. Addison-Wesley, New York. Brito, T., Ribeiro, T., Nóbrega H. and Elias, G. (2009) Uma Técnica de Indexação de Artefatos de Software Baseada em Dados Semi-Estruturados. In:III Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software (SBCARS 2009), p Ding, L. et al. (2004) Swoogle: A Semantic Web Search and Metadata Engine. In: 13 th ACM Conference on Information and Knowledge Management, p

17 16 Frakes, W. B. and Pole, T. P. (1994). An empirical study of representation methods for reusable software component, In: IEEE Transactions on Software Engineering, vol. 20, no. 8, p Frakes, W. B. and Kang, K. (2005). Software reuse research: status and future, In: IEEE Transaction Software Engineering, vol. 31, no. 7, p Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1997), Design patterns. Elements of reusable object-oriented software, Addison-Wesley. Garcia, V. C., Lucrédio, D., Durão, F. A., Santos, E. C. R., Almeida, E. S., Fortes, R. P. M. and Meira, S. R. L. (2006) From Specification to the Experimentation: a Software Component Search Engine Architecture, In: 9th International Symposium on Component-Based Software Engineering (CBSE 2006), p Girardi, M. and Ibrahim, B. (1994) Automatic Indexing of Software Artifacts, In: 3rd International Conference on Software Reuse, IEEE Computer Society Press, p Greenfield, J. and Short, K. (2004), Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools, Indianapolis Indiana: Wiley Publications Inc. Grosz, G. (1992) Building Information System Requirements Using Generic Structures, In: 16th Computer Software & Applications Conference (COMPSAC 92), p Hall, P. A. V. (1992), Software Reuse and Reverse Engineering in Practice, London: Chapman & Hall. Henninger, S. (1994) Using iterative refinement to find reusable software, In: IEEE Software, vol. 11, no. 5, p Henninger, S. (1997). An evolutionary approach to constructing effective software reuse repositories, In: ACM Transaction on Software Engineering and Methodology, vol. 6, no. 2, p Justo, J. L. B. (1996) A Repository to Support Requirement Specifications Reuse, In: Information Systems Congress of New Zealand (ISCNZ'96), p Kotonya, G., Lock, S. and Mariani, J. (2011), Scrapheap software sdevelopment: lessons from an experiment on opportunistic reuse, In: IEEE Software, vol. 28, no. 2, p Maarek, Y. S. and Smadja, F. A. (1989) Full Text Indexing Based on Lexical Relations, an Application: Software Libraries, In: Conference on Research and development in information retrieval (ACMSIGIR 89), p Maiden, N. and Sutcliffe, A. (1992). Exploiting reusable specifications through analogy. In: Communications of the ACM, vo1.35, no. 4, p Mcilroy, M. D. (1968). Mass produced software components. In: NATO Software Engineering Conference, Springer, p Melo, Cláudia de Oliveira. (2007), Classificação Semi-Automática de Componentes Java, Dissertação de Mestrado, Instituto de Matemática e Estatística da Universidade de São Paulo: São Paulo.

18 17 Neighbours, J. M. (1984), The draco approach to constructing software from reusable components, In: IEEE Transactions on Software Engineering, vol. 10, no. 5, p Parnas, D. L. (1976). On the design and development of program families. In: IEEE Transaction On Software Engineering, vol. 2, no. 1, p Petrov. I; and Buchmann, A. (2008) Architecture of OMG MOF-based Repository Systems, In: International Organization for Information Integration and Web-based Application and Services (iiwas2008), p Podgurski, A. and Pierce, L. (1993). Retrieving reusable software by sampling behavior. In: ACM Transaction on Software Engineering and Methodology, vol. 2, no. 3, p Prieto-Diaz, R. (1989) Classification of Reusable Modules in Software Reusability: Concepts and Models, In: Biggerstaff, T. J. and Perlis, A. J. (Editors). Addison-Wesley Pub. Co.: New York, NY, p Prieto-Diaz, R. (1991). Implementing faceted classification for software reuse. In: Communications of the ACM, vol. 34, no. 5, p Redolfi, G., Spagnoli, L., Hemesath, P., Bastos, R. M., Ribeiro, M. B., Cristal, M. and Espindola, A. (2005) A Reference Model for Reusable Components Description, In 38th Hawaii International Conference on System Sciences, p Salton, G. and Mcgill, M.J. (1983) Introduction to Modern Information Retrieval. McGraw- Hill, N.Y. Shiva, S. G., and Shala, L. A. (2007) Software Reuse: Research and Practice, In: 4th IEEE Conference Information Technology (ITNG 07), IEEE CS Press, p Sivashanmugam, K., Verma, K., Sheth, A. and Miller, J. (2003) Adding Semantics to Web Services Standards, In: International Conference on Web Services, p Sommerville, I. (2007) Engenharia de Software. 8ª ed. São Paulo: Pearson Addison Wesley. Sutcliffe, A. and Maiden, N. (1994) Domain Modeling for Reuse, In: 3rd International. Conference on Software Reuse, p Vanderlei, T. A., Garcia, V. C., Almeida, E. S. and Meira, S. R. L. (2006) Folksonomy in a Software Component Search Engine Cooperative Classification through Shared Metadata, In: XX Simpósio Brasileiro de Engenharia de Software (SBES), p Vanderlei, T. A., Durão, F. A., Garcia, V. C., Almeida, E. S. and Meira, S. R. L. (2007) A Cooperative Classification Mechanism for Search and Retrieval Software Components, In: 22th Annual ACM Symposium on Applied Computing (ACM SAC), p

19 18 Análise comparativa entre Groovy e Java, aplicado no desenvolvimento web Vandir Fernando Rezende, Marcel Hugo Departamento de Sistemas e Computação Universidade Regional de Blumenau (FURB) Blumenau, SC Brasil rezende.vandir@gmail.com,marcel@furb.br Resumo. Este artigo apresenta uma análise comparativa, no desenvolvimento de softwares web, entre as linguagens de programação Groovy e Java. Baseando-se na norma NBR ISO/IEC foram determinados os critérios de avaliação. Para permitir a comparação foi implementado um aplicativo estudo de caso em ambas as linguagens, com o intuito de medir a diferença de produtividade no desenvolvimento dos casos de usos. Para comparar o desenvolvimento, foi calculado a UCP dos casos de usos e posteriormente verificado o tempo e o desempenho em cada linguagem. 1. Introdução Com a necessidade de criar ferramentas que facilitassem o seu trabalho diário, o homem passou a aprimorar cada vez mais os computadores e seus sistemas (SAMPAIO, 1999). Diante da informatização dos processos, a linguagem de programação Java tem se mostrado importante, principalmente pelo fato de ser muito abrangente, pois contempla desde dispositivos móveis até mainframes. Para isso, a mesma utiliza-se de uma das suas principais características, a portabilidade (JAVA, 2010). Segundo Oliveira (2009), Java conta com inúmeros frameworks, cada um especializado em um ramo distinto do desenvolvimento de software, incluindo desde a modelagem do banco de dados até a criação das interfaces visuais. Para ter esta flexibilidade, Java precisa ser especificamente configurado a cada funcionalidade, pois não conta com configurações predefinidas, ocasionando assim uma perda de produtividade no processo, em casos que o tempo levado para configurar a solução é maior que o tempo gasto com o desenvolvimento da regra de negócio. Pensando neste fato, foram propostas diversas soluções para a evolução da linguagem Java, principalmente focando no desenvolvimento ágil. Assim surge o JRuby e o Grails (Groovy on Rails), tentativas de aproximar a programação Java com a filosofia ágil (PETERSON, 2010). Com o lançamento do framework Grails, para desenvolvimento de aplicações web, Groovy ganhou credibilidade e o interesse da comunidade Java, provando assim, que o desenvolvimento de aplicações web escaláveis são produtivas e fáceis. Grails utilizou desde recursos básicos do Groovy, até recursos complexos de aplicações web, como persistência em banco de dados, Ajax, webservices, relatórios, processamento em lote, e plugins que permitem aos desenvolvedores melhorar e criar novas ferramentas que auxiliam o desenvolvimento (JUDD; NUSAIRAT; SHINGLER, 2008).

20 19 Neste cenário, foi desenvolvido um aplicativo de gestão de projetos, sendo ele implementado em Java e em Groovy, com o intuito de comparar as linguagens. Tomouse como base para a análise comparativa a norma NBR ISO/IEC (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 2003). 2. NBR ISO/IEC A NBR ISO/IEC fornece um modelo de propósito geral, o qual define as seis amplas categorias de características de qualidade de software, que tem por objetivo servir de referência básica na avaliação de produto de software: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. Comparar linguagens de programação (LPS) não é exatamente o objetivo dessa norma, contudo é o documento técnico que mais se aproxima com o objetivo proposto. Desta forma, tornou-se necessário adaptar o modelo para a análise comparativa de linguagens de programação, elencando as características e subcaracterísticas que são relevantes a este tipo de comparação. Assim foram definidas as seguintes características como critérios de avaliação, a serem aplicados na análise comparativa: a) produtividade/custo: modificando o modelo proposto, a fim de atender a análise comparativa, foi incluso o item produtividade na categoria funcionalidade, onde Sebesta (2003) alega que de todos os fatores que contribuem para os custos da linguagem, três são os mais importantes: desenvolvimento do programa, manutenção e confiabilidade uma vez que essas são funções da capacidade de escrita e da legibilidade; b) usabilidade: nas linguagens de programação pode-se avaliar a dificuldade de entendimento (inteligibilidade) dos padrões utilizados nela, assim como o custo de aprendizado (apreensibilidade) dos programadores que estão ingressando na mesma; c) eficiência: através de programas gerados pela linguagem de programação, é possível medir o tempo de execução de determinado rotina ou caso de uso e quanto recurso de hardware foi utilizado para essa execução; d) manutenibilidade: o quanto a estrutura da linguagem auxilia na detecção de falhas (analisabilidade), assim como na alteração de códigos existentes (modificabilidade); e) confiabilidade: capacidade do programa em executar de acordo com as suas especificações sob todas as condições. A definição por estas características da qualidade e o entendimento de cada uma delas guiou a seleção das características das LPS a serem empregadas na comparação. 3. Características das Linguagens de Programação Para se tratar cientificamente a programação, deve ser possível especificar precisamente as propriedades necessárias dos programas. O formalismo não é necessariamente um fim por si só. A importância das especificações formais deve, no final, se justificar pela sua utilidade sejam elas usadas ou não para melhorar a qualidade do software ou reduzir os custos de produção e manutenção de software (J. HORNING apud TUCKER; NOONAN, 2008).