Ambiente de Desenvolvimento de Software para o Domínio de Administração Rural

Contato
Silvia M. F. Silveira Massruh
CNPTIA - EMBRAPA
Rodovia SP 65 Km 143,6 - Bairro dos Amarais
Caixa Postal 5.010
13.031-970 - Campinas - SP
e-mail: fms@cnptia.embrapa.br

Autoria
Silvia M. F. Silveira Massruhá - CNPTIA - EMBRAPA
Adauto L. Mancini - CNPTIA - EMBRAPA
Carlos Alberto A. Meira - CNPTIA - EMBRAPA
Fernando A. Máximo - CNPTIA - EMBRAPA
Renato Fileto e Sérgio L. Z. Passos - CNPTIA - EMBRAPA

RESUMO
Este trabalho descreve um ambiente de desenvolvimento de software para o domínio de administração rural, denominado FMS ("Farm Management Systems"). Este ambiente visa a produção automatizada de aplicativos para a gestão rural, de modo a fornecer aos produtores e extensionistas ferramentas para a obtenção rápida e confiável de informações sobre o seu processo produtivo.

O FMS é composto por dois módulos principais: o AEsp e o GFMS. O AEsp é um programa destinado a auxiliar na captura das especificações das aplicações e transformá-las, incrementalmente, em uma representação que pode ser traduzida para um programa operacional através do gerador de código fonte GFMS.

ABSTRACT
This paper decribes a software development environment for farm management systems, called FMS. This environment aims to generate farm management applications automaticaly, providing domain experts with tools for rapid and reliable information gathering about their productive process.

The FMS has two main modules: AEsp and GFMS. The AEsp is a program for capturing of informal specifications and converting them, incrementally, to a representation that can be translated to a operacional program by the application generator called GFMS.

1. Introdução

A produção de programas de computador a baixo custo é tão importante economicamente que muitas panacéias foram propostas e refutadas nos últimos 30 anos. A depuração dos resultados mostra que ganhos de produtividade têm sido lentos e que os melhores resultados foram alcançados quando se localizou o esforço numa área pequena e bem delimitada [FER93].

Os sistemas de apoio à gestão da pequena ou média propriedade agroindustrial têm características que os descreveriam, sob a ótica de engenharia de software, como pequenos, com pouca sofisticação de funções, baixa complexidade de dados e demandando uma interface com usuários simples e padronizada.

Por outro lado, a importância deste tipo de apoio não pode ser minimizado - é inconcebível que o administrador de uma pequena propriedade agrícola, básica na agricultura brasileira, não tome decisões amparado em informação quantificada e agregada sobre seu processo produtivo. Além disso, as informações sobre sua produção devem ser atualizadas e confiáveis de modo que possam ser inseridas nos sistemas de planejamento da agricultura.

O projeto FMS visa construir um processo produtivo para essa classe de programas a um custo decrescente com o tempo, transformando a experiência de cada produtor no ponto de partida do próximo sistema. Os sistemas gerados cobrirão algumas classes de aplicações e terão as características descritas acima. Este objetivo está sendo realizado através do desenvolvimento e integração de metodologias e ferramentas para a produção automatizada de aplicativos para o domínio de administração rural, buscando sempre a qualidade e produtividade na produção de software, a custos mínimos.

A abordagem utilizada pelo FMS é ilustrada na Figura 1. O usuário (especialista do domínio) é entrevistado pelo engenheiro de especificação que opera o programa assistente de especificação (AEsp). Tal programa auxilia o processo de decomposição e documentação da aplicação oferecendo aos usuários soluções já desenvolvidas e armazenadas durante sessões prévias de especificação. Estes programas especificados pelo produtor/extensionista são gerados automaticamente pelo gerador do FMS (GFMS) dispensando a maior parte do ciclo de manutenção.

Figura 1: Ambiente FMS

Gerar esses programas de forma automatizada é essencial, pois o custo de produção de uma enorme quantidade de aplicações nos moldes convencionais gera um problema econômico insolúvel. A geração automática de programas, mesmo que estes sejam simples e de aplicação bastante localizada, exige um elenco grande de ferramentas e tecnologias e é um problema técnico bastante atual.

Deve-se notar que o almejado pelo projeto FMS é baseado em processos com fundamentação estabelecida na literatura - criar um ambiente para a geração mais automatizada possível de programas para apoio a gestão da propriedade rural.

2. O Modelo do Ambiente FMS

A abordagem utilizada pelo FMS [FER93] prevê que, durante a fase de especificação do processo de desenvolvimento de software, as informações de uma aplicação sejam capturadas, decompostas e armazenadas para posterior reutilização. As informações devem ser decompostas até um nível de representação para o qual estará disponível um gerador de código fonte, dispensando a fase de implementação.

A definição do nível de representação, no escopo do Projeto FMS, foi realizada em duas etapas. A primeira etapa identificou o elenco de funções básicas e o modelo de fluxo de controle e de dados típico das aplicações do domínio de administração rural. A segunda etapa agregou esse conjunto de funções na forma de uma Linguagem de Composição do FMS (LC-FMS) e modelou as aplicações na forma de programas da classe reativa.

No modelo do FMS, os requisitos do usuário são transformados em uma especificação descrita em LC-FMS e a aplicação, gerada automaticamente a partir da especificação em LC-FMS, comporta-se como uma máquina de estados estendida. Para suportar esta abordagem, a metodologia subjacente ao FMS é baseada em um modelo de níveis.

O modelo de níveis do FMS propõe uma hierarquização entre os níveis do processo de transformação dos requisitos do usuário. O modelo utilizado é o modelo PW de Lehman [LEH84], no qual o nível não formalizado é descrito como nível conceitual e o nível onde já há uma descrição formal da aplicação é denominado nível operacional.

O processo de tradução dos requisitos dos usuários em uma representação formal (nível conceitual) é suportado por um assistente de especificação (AEsp).

O processo de transformação dos requisitos do usuário já descrito formalmente para um programa executável foi reduzido, ao processo de tradução entre os níveis da aplicação, representação e implementação [MAS94B]. A Figura 2 abaixo mostra essa hierarquização.

Nível da Aplicação

LA1 LA2 LA3 .......... LAn

Nível de Representação

"toolset" comum
gerador de programas da classe reativa
linguagem de composição - LC - FMS

Nível de Implementação

linguagem C
bibliotecas comuns

Figura 2: Hierarquização do Nível Operacional

No nível da aplicação, os requisitos do usuário já estão descritos formalmente e expressos em uma linguagem da aplicação(LA) [LEI90] que, posteriormente, é descrita em LC-FMS, isto é, traduzida para o nível de representação.

O nível de implementação é gerado pela tradução automática da especificação em LC-FMS (nível de representação) para uma implementação em Linguagem C através de um gerador de código fonte (GFMS).

A Figura 3 mostra o escopo do ambiente FMS sob o modelo PW que permite separar as etapas de abstração (coleta da especificação, incluindo reuso e prototipação) da etapa de concretização (geração automatizada de código).

Figura 3: O Escopo do Ambiente FMS

A arquitetura geral do FMS, como ilustra a Figura 3, é composta por duas ferramentas principais: o AEsp e o GFMS.

O AEsp é uma ferramenta, que visa auxiliar a captura das especificações das aplicações, através de uma entrevista, e transformá-las, incrementalmente, em uma representação formal que pode ser traduzida para um programa operacional.A arquitetura do AEsp é composta por vários módulos: Entrevistador, Prototipador, Montador, Catalogador e Reutilizador. Uma descrição detalhada destes módulos pode ser encontrada em [MAS94B].

O GFMS é uma ferramenta para geração do código fonte a partir da especificação formal [MEI91] capturada pelo AEsp. Esta especificação formal, descrita na Linguagem de Composição do FMS (LC-FMS), é composta por várias sublinguagens. As sublinguagens da LC-FMS são: Formulários, Consistências, Helps, Síntese dos Campos, Eventos e Ações (relatórios e operações relacionais).

A faceta do capturador de especificações do FMS demanda a integração de gerador de interfaces, bases de conhecimento, orientação a objetos, técnicas de análise de domínio e reuso. A faceta do gerador de aplicações do FMS utiliza técnicas de compilação, projeto lógico e físico de banco de dados, linguagens e metodologias de desenvolvimento de sistemas. A agregação dessas facetas tecnológicas na forma de um sistema funcional exige metodologias de integração de sistemas que é uma das correntes mais atuais, em termos de publicação, em Engenharia de Software [YEH91].

A plataforma de hardware para desenvolvimento do FMS, na versão corrente, é uma estação de trabalho com sistema operacional UNIX. Entretanto, a aplicação final é gerada para PC com sistema operacional MS-DOS, que é a plataforma usual para os usuários do domínio em questão.

3. Conclusão

As características do ambiente FMS, como implementado, são compatíveis com outros projetos deste tipo [MAS94A]. Embora o escopo do ambiente FMS seja mais limitado, supõe-se que essa focalização aumente a viabilidade deste ambiente.

A arquitetura do ambiente FMS encontra-se razoavelmente estabilizada. O AEsp tem parte de suas funcionalidades implementadas, porém, algumas de suas funções devem ser reimplementadas devido aos custos da plataforma de software sobre a qual esta ferramenta foi desenvolvida. O GFMS está operacional. Os compiladores das sublinguagens da LC-FMS estão implementados e estabilizados, exceto as sublinguagens de ações e consistências que estão sendo reestruturadas.

O ambiente FMS está sendo utilizado para definição, geração e evolução de um sistema de Controle de Rebanho Leiteiro - SisCoReb. A liberação de uma versão comercial deste sistema está prevista para o início de 1996.

A versão alfa do ambiente FMS está prevista para ser liberada para validação em julho de 1996.

A utilidade e a exequibilidade do modelo utilizado pelo ambiente FMS serão testadas através de sua utilização em larga escala.

A evolução do ambiente FMS está centrada na sofisticação da entrevista com o usuário, como consequência do crescente reuso de informações existentes nas bases de conhecimento, e na utilização de software padrão de mercado ( gerenciadores de base de dados e interface gráfica ( visando à minimização do custo de desenvolvimento do ambiente e a atualização dos sistemas prontos, conforme a evolução tecnológica.

4. Bibliografia

[FER93] FERRARETTO, M.D.; MASSRUHÁ, S.M.F.S. Projeto: ambiente de desenvolvimento de software para domínio de administração rural - FMS. Campinas/SP: EMBRAPA-CNPTIA, 1993. (Documento interno apresentado ao Sistema EMBRAPA de Planejamento - SEP)
[LEH84] LEHMAN, M.M. A futher model of coherent programming processes. Software Process Workshop, p. 27-35, 1984.
[LEI90] LEITE, J.C.S.P. O uso de hipertexto na elicitação de linguagens de aplicação. Simpósio Brasileiro de Engenharia de Software, 4, Águas de São Pedro, 24-26 de outubro de 1990. Anais. São Paulo: USP/CCS, 1990. p. 134-149.
[MAS94A] MASSRUHÁ, S.M.F.S. Um estudo sobre assistentes de especificação. Campinas/SP: EMBRAPA-CNPTIA, 1994. (Relatório Técnico)
[MAS94B] MASSRUHÁ, S.M.F.S et alli. AEsp: Um Assistente de Especificação. Simpósio Brasileiro de Engenharia de Software, 8, Curitiba, 25-28 de outubro de 1994. Anais. Paraná: PUC/PR, 1994. p. 311-324.
[MEI91] MEIRA, C.A.A. Sobre Geradores de Aplicação, São Carlos: USP/ICMSC, Setembro, 1991. (Tese de mestrado)
[YEH91] YEH, R.T et alli. A Comomsense management model, IEEE Software, p. 23-33, nov. 1991.