COMPONENTES PARA SOFTWARE AGROPECUÁRIO: ETAPAS DO DESENVOLVIMENTO RESUMO SOFTWARE COMPONENTS FOR THE AGRICULTURAL DOMAIN: DEVELOPMENT PHASES ABSTRACT

Transcrição

1 COMPONENTES PARA SOFTWARE AGROPECUÁRIO: ETAPAS DO DESENVOLVIMENTO REGINA BRAGA 1 FERNANDA CAMPOS 2 STAINAM BRANDÃO 3 DANIEL NICÁCIO 4 RESUMO O reuso de software é um dos objetivos de um desenvolvimento de software com qualidade. Apresentamos neste artigo o desenvolvimento de componentes de software para o domínio agropecuário e seu reuso no desenvolvimento de aplicações neste domínio. PALAVRAS-CHAVE: Componentes de software, reuso de software, Agropecuária. SOFTWARE COMPONENTS FOR THE AGRICULTURAL DOMAIN: DEVELOPMENT PHASES ABSTRACT The software reuse is one of the goals of a quality development process. We present in this article the development of software components for the agricultural domain and its use in development of applications in this domain. KEYWORDS: software components, reuse, agricultural domain. 1. INTRODUÇÃO O setor agropecuário é um setor de extrema importância para a população e para a economia, e se encontra em constante crescimento. Sua relação com a tecnologia a cada dia se estreita. Uma das áreas de maior relevância para o uso da informática é a pecuária leiteira e de corte (SILVA, 2002) (BRAGA ET AL., 2004), dada à complexidade operacional dos sistemas de produção e controle, seu significado para a alimentação da população e para a questão da rastreabilidade, onde é necessário todo o controle da vida do animal. Levantando em consideração a importância do desenvolvimento de novas aplicações no setor agropecuário e das vantagens do uso de DBC (Desenvolvimento Baseado em Componentes) 1 Regina Braga(doutora), Núcleo de Pesquisa em Qualidade de Software, Universidade Federal de Juiz de Fora; regina@acess.com; 2 Fernanda Campos (doutora) Núcleo de Pesquisa em Qualidade de Software, Universidade Federal de Juiz de Fora; fcampos@dcc.ufjf.br; 3 Stainam Brandão(mestrando) 4 Daniel Nicácio (graduando)

2 (BROWN & WALLNAU, 1998), em parceria com o CNPTIA da Embrapa e com a Vale Verde Agropecuária, apresentamos neste artigo as etapas envolvidas no desenvolvimento de um conjunto de componentes de software voltados para o domínio agropecuário. A disponibilização destes componentes para a comunidade de desenvolvedores de software agropecuário traz como benefícios imediatos o aumento de produtividade e redução de custos no desenvolvimento de aplicações para o domínio agropecuário, além do treinamento e utilização de técnicas avançadas de desenvolvimento de software. Para que o desenvolvimento de componentes de software seja realizado de maneira adequada, necessitamos de um processo de desenvolvimento bem definido e do suporte de um ambiente de desenvolvimento adequado a DBC. Neste projeto usamos um ambiente para o desenvolvimento de componentes, denominado OdysseyShare (WERNER ET AL., 2003) e a metodologia Odyssey_DE_Componentes, que é uma adaptação da metodologia para engenharia de domínio Odyssey_DE (BRAGA ET AL., 2001) e da metodologia UML Components (CHEESMAN & DANIELS, 2001). A adaptação foi feita a partir da experiência da equipe em projetos anteriores envolvendo DBC e das deficiências encontradas nestas e em outras metodologias de DBC pesquisadas na literatura. O objetivo deste artigo é apresentar o processo de especificação de componentes para o domínio agropecuário. Para tanto, o artigo está organizado da seguinte forma: na seção 2 descrevemos, em linhas gerais, o domínio agropecuário. A seção 3 apresenta a metodologia Odyssey_DE_Componentes e discute a escolha por definir uma metodologia adaptada para o projeto, detalhando os modelos especificados para um dos componentes desenvolvidos. Na seção 4 apresentamos as conclusões. 2 - DOMÍNIO AGROPECUÁRIO No Brasil, cuja prática agrícola e pecuária ainda está longe de se situar entre as mais modernas do mundo, há a consciência de que a tecnologia significa um grande diferencial na questão da redução dos custos, ganho de produtividade e redução de riscos das atividades. Portanto, muitos estudos e pesquisas voltados para o setor foram e estão sendo desenvolvidos. O setor agropecuário é muito extenso e há várias linhas de atuação onde se deseja investir em tecnologia. Uma das áreas de maior relevância para o uso da informática é a pecuária leiteira, dada à complexidade operacional dos sistemas de produção de leite, seu significado para a alimentação da população e a nova questão que vem surgindo com a

3 rastreabilidade 2, onde será necessário todo o controle da vida do animal (MACHADO ET AL., 2002). Neste cenário da agropecuária brasileira e sua necessidade de inovação tecnológica, temos como objetivo desenvolver componentes de software para o setor agropecuário e como ponto de partida, foi escolhido o subdomínio de controle leiteiro e posteriormente o de rastreabilidade. A partir de uma taxonomia para o setor de software agropecuário (COELHO ET AL., 2000), (PROCACI ET AL., 2002) e contando com apoio de especialistas do domínio da Embrapa e da Vale Verde Agropecuária, estão sendo selecionados subdomínios (como é o caso do controle leiteiro e rastreabilidade) com maior potencial de reuso em produtos do setor, tanto de software de gerenciamento e controle quanto aos produtos dedicados a área de rastreabilidade. Esses especialistas ajudam na validação dos componentes desenvolvidos no trabalho através do seu uso em aplicações no domínio, na detecção das carências do setor e nos fornecem todo o suporte para o desenvolvimento dos componentes. Nosso objetivo principal ao definirmos esta taxonomia para o domínio agropecuário é a identificação de conceitos e funcionalidades importantes que ajudem no desenvolvimento de componentes de software no domínio e também na identificação, busca e seleção destes componentes para posterior reuso. Para se criar uma taxonomia em uma área do conhecimento é preciso definir os conceitos mais usados na área, os relacionando e representando em redes semânticas. Neste projeto para representar os termos capturados no domínio especificamos um modelo de domínio (BRAGA ET AL., 2001). Este modelo, que engloba termos e funcionalidades comumente usados pela comunidade permite a reutilização e o compartilhamento de um vocabulário comum entre desenvolvedores e usuários de softwares das mais diversas origens, permitindo assim uma classificação mais precisa dos mais diversos tipos de software relacionados ao domínio e conseqüentemente de componentes de software a serem reutilizados em novas aplicações. O modelo que especifica os termos do domínio, formando 2 A rastreabilidade é a correspondência única entre uma referência e um produto, identificado por lote ou individualmente O animal recebe um código de identificação único e é registrado em um banco de dados, onde deverão ser armazenadas todas as informações relevantes à vida do animal (SILVA, 2002). Se ocorrer uma anormalidade com esse animal é possível de forma rápida e eficaz, consultar o seu histórico(rastros) e obter informações que permitirão a identificação da causa da anormalidade e a tomada de ações para a solução do problema.

4 assim uma rede semântica de termos, é denominado de modelo de features 3 (figura 1). A definição da taxonomia do domínio foi feita a partir de uma das etapas da metodologia Odyssey-DE_Componentes. O modelo foi criado de maneira que novos termos possam ser adicionados de acordo com o surgimento de componentes de software em áreas não cobertas na taxonomia original. Ao relacionar os componentes de software com os termos do domínio, os desenvolvedores de software (reutilizadores de componentes), poderão selecionar os componentes a serem reutilizados em suas aplicações de maneira mais facilitada, uma vez que esta seleção parte de termos comumente utilizados no domínio. 3 METODOLOGIA ODYSSEY_DE_COMPONENTES O Odyssey-DE (BRAGA ET AL., 1999) é um processo de engenharia de domínio (ED) que enfoca, de maneira sistemática, o desenvolvimento de componentes com ênfase no entendimento dos artefatos reutilizáveis que existem em um dado domínio. Assim, a abordagem do Odyssey-DE une os aspectos de reutilização e entendimento do domínio e a identificação de componentes reutilizáveis, mesmo que ainda em um nível de abstração alto. Portanto, o Odyssey-DE segue uma abordagem de desenvolvimento para reutilização, ou seja, o desenvolvimento de artefatos reutilizáveis. No suporte ao desenvolvimento de componentes, porém, este processo apresenta falhas, e o maior problema do Odyssey-DE é que ele enfatiza principalmente a fase de análise do domínio e não detalha de maneira adequada a especificação dos componentes, ou seja, faz somente o papel de identificador de quais componentes são passíveis de reutilização. 3 Um modelo de features é um modelo que captura as características (features) gerais das aplicações desenvolvidas em um domínio. Assim, as similaridades e diferenças entre as aplicações são explicitadas através das features, classificadas de forma hierárquica no modelo.

5 Rastro entre modelos para facilitar a busca por modelos e componentes relacionados ao conceito Figura 1 - Modelo de Features visão parcial do sub-domínio de Controle Leiteiro Para contemplar esta etapa de especificação de componentes, precisamos de um maior detalhamento das etapas de projeto dos componentes e não apenas de sua identificação. Desta forma, analisando as alternativas disponíveis, optamos por adaptar a metodologia Odyssey_DE, acrescentando características específicas de metodologias de DBC, com ênfase na metodologia UML Components(CHEESMAN & DANIELS, 2001). A partir desta adaptação, surgiu a metodologia Odyssey_DE_Componentes. A Odyssey-DE-Componentes é importante uma vez que fornece uma melhor sistemática para o desenvolvimento de componentes com reutilização, em todas as suas fases, facilitando a reutilização e atenuando as deficiências levantadas anteriormente. O processo de desenvolvimento de componentes com reutilização através desta visão envolve quatro fases: análise de domínio, especificação dos componentes, provisão e montagem. Veremos agora uma descrição simplificada destas fases apresentando modelos referentes ao domínio de agropecuária com ênfase no desenvolvimento de um componente específico do domínio, que é um componente para gerenciamento de descartes no rebanho leiteiro mas que também pode ser reutilizado para rebanho de corte.

6 3.1 ANÁLISE DO DOMÍNIO Nesta primeira fase estamos preocupados com a definição e especificação dos requisitos do problema. É onde ocorre o entendimento dos processos do negócio no domínio, ou seja, identificamos e organizamos o conhecimento sobre uma classe de problemas, o domínio do problema, para suportar sua descrição e solução. Através da análise do domínio definimos os principais conceitos do domínio ressaltando suas similaridades e diferenças em um nível de abstração que seja de fácil entendimento para os usuários. A principal maneira de elicitarmos este conhecimento a respeito das principais similaridades e diferenças do domínio é conseguido através de casos de uso e do modelo de features. Os casos de uso permitem o detalhamento dos passos e captura dos conceitos pertinentes aos mesmos, assim como permitem também a identificação das principais funcionalidades do domínio. Todo este processo é interativo e incremental. Devemos capturar apenas as funcionalidades mais importantes e abstraí-las, tendo como resultado um conjunto de casos de uso abstratos que atendem a diversas aplicações em um domínio. O modelo de features é o modelo de domínio mais característico da análise de domínio e é a primeira abstração para componentes. Para isso ele se propõe a um detalhamento maior dos conceitos apresentados nos modelos, fazendo uma descrição mais precisa dos mesmos, similar a uma taxonomia. A figura 1 apresenta uma visão parcial do modelo de features. A especificação de componentes é dividida em três estágios intermediários: identificação de componentes, especificação de componentes e interação de componentes. Analisando o modelo de features e de casos de uso, vindos da etapa de análise do domínio, começamos a identificar os possíveis componentes, ou seja, agrupando os principais conceitos e funcionalidades do domínio combinado às ações identificadas nos casos de uso (figura 2), começamos a ter uma idéia do conjunto inicial de interfaces e especificações dos componentes. 3.2 ESPECIFICAÇÃO DE COMPONENTES A identificação de interfaces é baseada na utilização dos passos dos casos de uso para se identificar as operações que estarão sob responsabilidade dos componentes a serem desenvolvidos (figura 2). Para cada passo de um caso de uso, os componentes podem prover, nenhuma, uma ou várias operações para preencher suas responsabilidades. Portanto, as interfaces e suas operações iniciais são derivadas da descrição dos casos de uso.com a criação da especificação inicial das interfaces para cada interface identificada na atividade anterior, vamos criar pacotes onde teremos a interface criada e seus tipos identificados como

7 associados (estes tipos são derivados dos termos identificados no modelo de features). Em geral, para cada uma das interfaces identificadas e/ou reutilizadas anteriormente iremos criar uma especificação de componentes separada, para depois construirmos a arquitetura de componentes (figura 3), ou seja, como serão as interações entre os mesmos. Um componente pode apresentar uma ou mais interfaces. A próxima etapa é a de interação entre componentes. Esta fase tem o objetivo de refinar as definições de interface existentes, identificar como as interfaces serão usadas e descobrir novas interfaces e operações (figura 3). Para isso, partimos das interfaces funcionais, as quais foram derivadas dos casos de uso, e criamos um ou mais diagramas de colaboração que mostrarão qualquer restrição resultante da invocação de determinada operação. Outro ponto importante do estudo de colaboração entre componentes é a quebra de dependências entre os mesmos, uma vez que ele deve ser o mais genérico e independente possível para poder ser reutilizado em outras aplicações do domínio (ex: componente de descarte pode ser utilizado tanto no controle leiteiro quanto para gado de corte). Por conta desta restrição pode ser necessário adicionar novas operações às interfaces dos componentes e novas interações entre componentes. 3.3 PROVISÃO A provisão determina quais componentes comprar, implementar, adaptar ou integrar com base nos resultados da especificação. Novamente, a busca em repositórios de componentes já existentes é muito importante nesta etapa. Esta busca, baseada no modelo de features do domínio e também nas interfaces especificadas, permite uma maior chance de sucesso na busca por componentes que possam ser reutilizados, necessitando ou não de alguma adaptação para a tecnologia e arquiteturas propostas. Se a busca por componentes previamente desenvolvidos não for satisfatória, devemos utilizar o conjunto de especificações dos componentes para a implementação dos componentes utilizando um modelo de componentes (EJB,.NET, etc). No caso específico do componente de descartes, o mesmo foi implementado utilizando as tecnologias EJB 4 e Delphi, com o objetivo de contemplar as aplicações dos parceiros e tecnologias utilizadas nestas aplicações. 4 É importante ressaltar que o componente de descarte é um componente lógico, que no caso específico da tecnologia EJB, deu origem a vários componentes Entity e Session.

8 Figura 2 Ações identificadas no detalhamento do caso de uso Determina Animais para Descarte Figura 3 Arquitetura de Componentes (modelo parcial) 4. CONCLUSÕES Este trabalho descreveu e ilustrou o processo de desenvolvimento de componentes de software para agropecuária. Apresentou, também as principais etapas da documentação e

9 desenvolvimento dos componentes. Utilizamos a metodologia Odyssey-DE_Componentes nas diversas etapas inerentes ao desenvolvimento de componentes. Com o intuito de avaliarmos a aplicabilidade dos componentes desenvolvidos, estamos gradativamente integrando estes componentes em aplicações do domínio, em parceria com empresas locais do setor (ex. Vale Verde Com ajuda de especialistas e desenvolvedores do domínio, estamos validando a utilização dos mesmos nestas aplicações. Podemos relatar que até o momento os resultados se mostram promissores. 5. AGRADECIMENTOS: À FAPEMIG, ao CNPq, à UFJF pelo apoio financeiro, ao Projeto Odyssey COPPE/Sistemas-UFRJ, a Embrapa e Vale Verde Informática. 6. REFERÊNCIAS BIBLIOGRÁFICAS BRAGA, R, MATTOSO, M, WERNER, C., The Use of Mediation e Ontology Technologies for Software Component Information Retrieval, In: ACM Symposium on Software Reusability (SSR 01), Anais do ACM Symposium on Software Reusability (SSR 01), págs , Toronto, Ontario, Canadá, BRAGA, R.; WERNER, C. & MATTOSO, M., Odyssey: A Reuse Environment based on Domain Models. In: IEEE Symposium on Application-Specific Systems and Software Engineering Technology (ASSET'99), Anais do IEEE Symposium on Application- Specific Systems and Software Engineering Technology,Richardson, Texas, Março, BRAGA, R; CAMPOS, F.; PROCACI, A; ALVES, J.; OLIVEIRA, A, SBS-Agro: Sistema de Busca Utilizando Mapeamentos Ontológicos e Retorno do Usuário, Revista Brasileira de Informática Aplicada a Agropecuária, BROWN, A., WALLNAU, K., The Current State of CBSE, IEEE Software, pp , CHEESMAN, J., DANIELS, J., UML Components A simple Process for Especifying Component-Based Software. Addison Wesley Longman, COELHO,F.,CAMPOS,F.,BRAGA,R.M. METODOLOGIA DE AVALIAÇÃO DE SOFTWARE AGROPECUÁRIO - PROPOSTA DE UMA ONTOLOGIA PARA O SETOR In: Infoagro 2000 Anais do Infoagro 2000.,2000. MACHADO, J.; NANTES, J.; ROCHA, C.; O processo de informatização das propriedades rurais: um estudo multicaso na pecuária de corte, Revista Brasileira de AgroInformática, V. 4, num 1, ISSN , 2002 PROCACI, A.; ALVES, J.W..; BRAGA, R.M.M.; CAMPOS, F. C., SBS-Agro: Sistema de Busca Utilizando Ontologias e Retorno do Usuário, In: XXVIII Conferência Latino Americana, Anais do XXVIII Conferência Latino Americana,Uruguai, novembro 2002.

10 SILVA, K.N., Rastreabilidade da carne, Disponível em < acessado em13/01/2001. WERNER, Claudia; MATTOSO, Marta; VIEIRA, Vaninha; BORGES, Marcos; MANGAN, Marco; BRAGA, Regina Maria Maciel; CAMPOS, Fernanda. OdysseyShare: Desenvolvimento Colaborativo de Componentes. In: IX SIMPÓSIO BRASILEIRO DE SISTEMAS MULTIMÍDIA E WEB, 2003, Salvador. WEBMIDIA