MODELLING OF AGRICULTURAL MANAGEMENT SYSTEM OF MARANHÃO (SGAMA) USING UML Lucélia Lima Souza Universidade Ceuma, Maranhão, Brasil lucelialsouza@msn.com Yonara Costa Magalhães Universidade Ceuma, Maranhão, Brasil yonara.magalhaes@ceuma.br Will Ribamar Mendes Almeida Universidade Ceuma, Maranhão, Brasil will75@gmail.com Abstract: This paper describes the modeling of agricultural management system of Maranhão (SGAMA), an organ in charged of the animal advocacy of the State of Maranhão (Brazil), using the UML in the version 2.3. To this modeling it was developed activities related to the analysis of scenario AGED-MA together with the managers and operators in order to identify the needs of the system; the lifting of system requirements through interviews among users and experts related to the SGAMA; so, too, identifications of the business rules necessary to the organ; documentation of Use Cases of use through the model of a proper textual artifact whide described the scenarios; and the elaborations of diagrams of Use Case, Class, Sequence and Activity of the main functionality of the system. The system SGMA-MA is responsible for controlling the data referent, too the producers, proprieties, proprieters and cattle of Maranhão, so permitting the control and mapping of the animal vaccine, diseases and animal traffic organized by the Central Unit and other unites whide comprise the operational structure of AGED-MA. Keywords: UML, Diagrams, Functional Requirements, Business Rules. Thanks: The authors acknowledge the financial support of the University CEUMA, the Coordination of Improvement of Higher Education Personnel - CAPES, CNPq and FAPEMA-MA during the development of this work 1672
MODELAGEM DO SISTEMA DE GERENCIAMENTO AGROPECUÁRIO DO MARANHÃO (SGAMA) UTILIZANDO A UML Resumo: Este artigo descreve a modelagem do Sistema de Gerenciamento Agropecuário do Maranhão (SGAMA), órgão encarregado da defesa animal do Estado do Maranhão, utilizando a UML na versão 2.3. Para esta modelagem foram desenvolvidas atividades relacionadas à análise do cenário do sistema na AGED-MA junto aos gestores e operadores de modo a identificar as necessidades do sistema; levantamento dos requisitos do sistema por meio de entrevistas com usuários e especialistas relacionado ao SGAMA; identificação das regras de negócio necessárias ao órgão; documentação dos Casos de Uso por meio de um modelo de artefato textual próprio que descreveu os cenários; e a elaboração dos diagramas de Caso de Uso, Classes, Sequência e Atividade das principais funcionalidades do sistema. O sistema SGMA-MA é responsável por controlar os dados referentes aos produtores, propriedades, proprietários e rebanhos do Maranhão, permitindo o controle e o mapeamento da vacinação animal, doenças e o trânsito animal de modo organizado por parte da Unidade Central e demais Unidades que compõem a estrutura operacional da AGED-MA. Palavras-chave: UML, Diagramas, Requisitos Funcionais, Regras de Negócio. Agradecimentos: Os autores agradecem o apoio financeiro da Universidade Ceuma, da Coordenação de Aperfeiçoamento de Pessoal de Nível Superior CAPES, do CNPQ e da FAPEMA-MA durante o desenvolvimento deste trabalho.. 1673
1 INTRODUÇÃO O processo de informatização relacionado à Pecuária tem tido um papel fundamental no processo de modernização nesta área, tendo em vista a necessidade crescente do aumento da produtividade e de um maior rigor no controle dos rebanhos, visando-se a melhoria da qualidade desse tipo de produto. Anteriormente, esta informatização somente era aplicada de forma administrativa pelos produtores. Entretanto, esta visão teve que ser ampliada e ressignificada devido à existência de normas e instituições de controle animal que exigem cada vez mais a comprovação do atestado de qualidade dos rebanhos, principalmente quando isto envolver acordos comerciais internacionais. Desse modo, esses órgãos e instituições precisam constantemente desenvolver e utilizar sistemas informatizados que os auxiliem no controle de produção, no transporte animal, no planejamento, no controle e execução de campanhas de vacinação animais realizadas por cada produtor. E isto de deve ser feito de forma a estabelecer um padrão de controle dessas atividades de maneira bastante simples e ágil. O Sistema de Gerenciamento Agropecuário do Maranhão SGAMA surgiu da necessidade dos funcionários da AGED Agência Estadual de Defesa Agropecuária do Maranhão, em controlar os dados necessários para realizar suas análises, em relação aos produtores, propriedades, proprietários, explorações etc. Ao ter esses dados a AGED-MA conseguirá controlar a inserção de novos produtores e proprietários, bem como a respectiva atualização dos dados cadastrais relacionadas a eles (tipo de rebanho, quantidade, vacinações, inspeções, transporte). Desta forma, a agência terá de forma organizada as informações relacionadas aos rebanhos do Maranhão de forma ágil e sem gerar duplicidade de informações. Além de permitir a quantificação dos gados vacinados nos períodos das campanhas de vacinação desenvolvidas pelo órgão e que são exigidos por lei. Isto possibilitará gerar-se relatórios gerenciais de acompanhamento do setor pecuário estadual para o planejamento e a tomada de decisões de ações desenvolvidas nesta área. A importância da proposta se dá pelo fato das informações serem anteriormente mantidas por meio de formulários impressos, o que tornava a operacionalização dos dados e das informações mais lento, e muitas vezes mais complexo, pois algumas ações eram passíveis de erro e demora na consolidação das informações, a exemplo de: colunas trocadas, erros de digitação de CPF. Já na versão proposta, é utilizado um banco de dados para melhor armazenamento e classificação dos dados gerando assim o relatório mais confiável e automatizado. Em suma: a escolha deste tema é justificada pela necessidade de se documentar, analisar, especificar, organizar e visualizar o sistema por meio da modelagem com o intuito de propiciar um sistema mais robusto capaz de atender as necessidades dos usuários de forma a produzir informações para o controle e o gerenciamento agropecuário, permitindo uma gestão adequada das informações de modo a subsidiar a tomada de decisão. 1674
Para o desenvolvimento da modelagem do sistema SGAMA (Sistema de Gerenciamento Agropecuário do Maranhão) foi utilizada a linguagem padrão da UML (Linguagem de Modelagem Unificada) para documentar o sistema, facilitar as manutenções e correções, e ao mesmo tempo atender às necessidades dos usuários. Para isso, foi necessário analisar todo o cenário o sistema, fazendo-se um estudo exploratório de suas principais necessidades. Assim, foi realizado um levantando de requisitos funcionais e não funcionais, aplicando técnicas de entrevistas e questionários, identificando as regras de negócio, documentando os Casos de Usos UCs, por meio de um modelo de artefato textual é descrito os cenários e elaborado os principais diagramas de funcionalidades do sistema proposto. Deste modo, este trabalho é dividido em mais quatro partes. Na segunda seção são apresentados a linguagem de modelagem UML e o processo RUP para o SGAMA, expondo suas principais características, conceitos e elementos envolvidos. A terceira seção apresenta a metodologia utilizada para o desenvolvimento da modelagem do SGMA. A quarta seção descreve a visão geral do negócio e do sistema, bem como as funcionalidades identificadas. E na quinta seção é detalhado o processo de desenvolvimento do sistema em relação às quatro fases do RUP, a saber: concepção, onde são descritos os requisitos funcionais, não-funcionais e as regras de negocio; elaboração, que mostra a modelagem do sistema, por meio da descrição textual dos casos de uso e os demais diagramas da UML; construção, que apresenta algumas das telas principais do sistema já implementado. 2 FUNDAMENTAÇÃO TEÓRICA 2.1 UML O surgimento da Unified Modeling Language, doravante identificada com (UML) e traduzida como Linguagem de Modelagem Unificada, aconteceu por volta de 1996 quando os três amigos Grady Booch, James Rumbaugh e Ivar Jacobson, aproveitaram para pesquisar sobre diversas anotações preexistentes. Em 1997, a UML, foi aprovada como padrão pelo Object Management Group OMG. (BEZERRA, 2007). Desde então, têm surgindo várias versões que a faz tornar-se mais clara e útil. Atualmente, está na versão 2.3 A UML é uma linguagem-padrão para a elaboração da estrutura de projetos de software e que pode ser utilizada para visualização, especificação, construção e documentação de artefatos que fazem uso de sistemas muitos complexos (BOOCH, RUMBAUGH e JACOBSON, 2000). 2.2.1 Diagramas da UML Atualmente, a UML, em sua mais nova versão a 2.3, contempla 14 diagramas, dividida em dois grupos: Diagramas Estruturais e Diagramas Dinâmicos. Além de contar com uma subcategoria designada Diagrama de Interação, composta por quatro diagramas: Sequência, Comunicação, Temporal e Visão Geral (OMG, 2013) 1675
Guedes (2011, p. 30), explica por que a existência de tantos diagramas: Por que a UML é composta por tantos diagramas? O objetivo disso é fornecer múltiplas visões do sistema a ser modelado, analisando-o e modelando sob diversos aspectos, procurando-se, assim, atingir a completitude da modelagem, permitindo que cada diagrama complemente os outros. Deste modo, os inúmeros diagramas existentes permitirão representar as visões do sistema em seu diferente aspectos, além de ensejar seu entendimento à medida que forem elaborados; ao mesmo tempo contempla também os múltiplos usuários. Um diagrama tem como principal objetivo sua representação gráfica de um conjunto de elementos que são modelados para uma melhor visualização de um sistema. Para saber como e quando aplicar um diagrama deve-se entender o que cada diagrama oferece. Pois poderá ocorrer que uma situação não possa ser representada somente com um diagrama e, sim, com vários, de modo a auxiliar na compreensão do sistema que está sendo desenvolvido. Os 14 diagramas da UML 2.3 estão representados hierarquicamente, conforme a figura 1. Figura 1 Diagrama da UML 2.3 Fonte: (Sbrocco, 2011) 1676
Os diagramas que apresentam um asterisco (*) são novos na versão 2.0. Foram mantidos na versão 2.2. Já o diagrama marcado com duplo asterisco (**) é novo na versão 2.2 (MELO, 2010). E mantido na versão 2.3. Conforme Lima (2011, p. 34), todo diagrama é constituído de elementos, cada um com um propósito, regras e notações diferentes para definir uma situação do processo de desenho. Conforme OMG (2013), os diagramas, já citados, são definidos em duas categorias na versão 2.3 logo a seguir, a saber: a) Diagramas Estruturais Descreve a estrutura estática do sistema, ou seja: suas partes abstratas (esqueleto) conforme suas ligações são eles: Diagrama de Classe: representa a estrutura lógica, descrevendo as estrutura das classes, determinando os atributos e métodos de cada classes, é o mais usado e um dos mais importantes da UML. Diagrama de Objeto: representa os objetos e suas interações associado ao diagrama de classes. Diagrama de Pacote: representa os pacotes, isto é, os subsistemas ou submódulos determinando suas partes. É utilizado para apresentar a arquitetura de uma linguagem, definindo suas camadas. Diagrama de Componente: representa a estrutura física do software, apresentando suas interfaces. Exemplo: bibliotecas, formulários, módulos de código-fonte, arquivo de ajuda, etc. Diagrama de Estrutura Composta: descreve a estrutura interna, detalhadamente suas partes e como se comunicam colaborando entre si. Diagrama de Implantação: mostra o conjunto de elementos da arquitetura de execução do sistema que representa a sua implantação. Diagrama de Perfil: permite mostrar os mecanismos de extensão adaptado ao metamodelos em diferentes plataformas (J2EE ou NET). Ele define os estereótipos, valores e restrições. b) Diagramas Dinâmicos (Comportamentais) Descreve os comportamentos dinâmicos dos objetos de um sistema, que são alterados e descritos ao longo do tempo (OMG, 2013), são eles: Diagrama de Caso de Uso: representa as interações do usuário com o sistema, ou seja, descreve suas ações (caso de uso), e que o sistema poderá executar ou não através da comunicação com usuários externos do sistema (atores). 1677
Diagrama de Atividade: mostra a modelagem do comportamento do sistema, a saber, os caminhos lógicos dos seus processos representando o fluxo dos eventos. Diagrama de Estado de Máquina: representa os modelos de estado, que mostra a maneira que eles agem e respondem aos seus eventos. Diagrama de Interação: é um subconjunto de diagrama, que controla o fluxo de dados dos elementos que são modelados, incluídos quatro tipos de esquema: diagrama de sequência, comunicação, temporal e visão geral. Diagrama de Sequência: mostra a interação de uma sequência de mensagens trocadas entres os objetos (linha de vida), ordenando sua sequência de comportamento. Diagrama de Comunicação: até UML 1.4 conhecida como Diagrama de Colaboração. Permite modelar a interação dos objetos de sequência simples, entre linhas de vida. Essa sequência de mensagens é numerada. Diagrama Temporal: é representado por uma escala de tempo que enseja especificar-se as mudanças de estado de um objeto ao longo da linha de vida. Diagrama Visão Geral: Representa o fluxo de controle de modo geral dentro de um sistema ou seu processo de negócio. 2.2 RUP - Rational Unified Process Segundo Scott (2003), o Processo Unificado (PU) teve sua origem no fim da década de 1960 por Ivar Jacobson e sua equipe na Ericson. Na época, modelaram um sistema de telecomunicações muito complexo e por isso utilizavam camadas de blocos conhecido como componentes. Eles construíram blocos de baixo nível conhecido como casos de tráfego e hoje denominados como casos de uso na UML. Anos depois, Jacobson saiu da empresa e criou uma campanha chamada Objectory AB e que, consequentemente, foi comprada pela Rational, do qual o Grady Booch e Jim Rumbaugh já faziam parte da Rational. Juntos se tornaram grandes amigos na expansão do método unificado conhecido como a Linguagem de Modelagem Unifica (UML) e construíram o Processo Objectory da Rational (ROP) que em 1998, a Rational mudou seu nome para RUP. O RUP (Rational Unified Process) é um processo padronizado para desenvolvimento de software que usa a UML (Unified Modeling Language) para especificar o sistema. Ele foi criado e comercializado pela empresa Rational. (SCOTT, 2003). 1678
Este processo tem como principais característica o desenvolvimento das melhores práticas de software, por meio do ciclo de vida iterativo e incremental, utilizando a UML, caso de uso e cenários e também por ser centrada na arquitetura de software, facilitando a manutenção e reutilização. Garantirá um software de alta qualidade respeitando as limitações de prazo e menor custo de acordo com as necessidades dos usuários. Os processos da RUP definem as atividades de cada um na equipe quem esta executando o que e quando (MARTIN, 2010). A seguir, serão apresentadas as quatro fases do RUP e suas definições, como mostra na figura 2. Figura 2 Fases do RUP Fonte: adaptado de Kruchten (2003) Conforme Kruchten (2003), utiliza-se a metodologia do RUP Rational Unified Process e suas 4 fases: concepção, elaboração, construção e transição;, assim foi desenvolvido a documentação do sistema SGAMA. 2.2.1 Concepção Nesta fase inicial, é definida a visão geral de todo o escopo do sistema SGAMA. Nela foram levantados todos os requisitos funcionais e não funcionais e regras de negócio do sistema, conforme as entrevistas e questionários aplicados. Esta fase, objetiva identificar as entidades externas (pessoas e sistemas) que interagem e avaliam as informações de contribuição do sistema com o negócio (SOMMERVILLE, 2007). O primeiro passo definido após de toda análise do sistema foi a identificação dos requisitos funcionais e requisitos não-funcionais juntamente com suas regras de negócios. Cumpre lembrar que, na construção de todo trabalho, foi voltado para fase de concepção e elaboração do processo, tendo sido analisado e feito todo um levantamento de requisitos e assim posteriormente modelados por meio de diagramas. 1679
Requisitos Funcionais RF Segundo Sommerville (2007, p. 80), os requisitos funcionais são as declarações específicas e como o sistema deverá comportar-se em determinadas situações. Nessa fase foram apresentados os requisitos funcionais do sistema SGAMA, conforme identificação levantada do que é permitido ou não no sistema, segundo as suas funcionalidade. Requisitos Não-Funcionais RNFs Conforme (SOMMERVILLE, 2007, p. 80), são restrições sobre os serviços ou as funções oferecidas pelo sistema. De acordo com essas restrições o usuário poderá acessar o sistema de forma segura seguindo as normas apresentadas pelo negócio. Regras de Negócio RN Regras de Negócio (RN) são políticas, condições ou restrições que deverão ser consideradas na execução dos processos existentes em uma organização (BEZERRA, 2007). Geralmente, as regras de negócio são identificadas na fase de levantamento de requisitos. Ao analisar-se o ambiente do negócio, detectam-se as restrições necessárias para o seu funcionamento. 2.2.2 Elaboração Nesta fase seguem-se as descrição dos requisitos funcionais, não-funcionais e das regras de negócio de acordo com as suas funcionalidades definidas no sistema. Cada funcionalidade (definida como caso de uso) representará as ações do sistema, que, consequentemente, serão modelados nos diagramas. Segundo Sommerville (2007), esta fase é desenvolvida após o entendimento do domínio do problema. Nela se utiliza um framework de arquitetura para o sistema e desenvolve-se um plano de projeto para identificação dos principais riscos. Descrição Textual do Use Case (UC) Segundo Pressman (2006), os cenários conhecidos também como caso de uso, descrevem de forma detalhada como o sistema será utilizado. Dessa forma, foram apresentados os Use Case UC, também conhecidos como Casos de Uso, identificados no sistema SGAMA, conforme o levantamento dos requisitos. Diagramas da UML A UML é uma linguagem-padrão para a elaboração da estrutura de projetos de software e que poderá ser utilizada para visualização, especificação, construção e documentação de artefatos que fazem uso de sistemas muitos complexos (BOOCH, RUMBAUGH e JACOBSON, 2000). De acordo com as necessidades do sistema são construídos os diagramas para sua maior compreensão; por isso, o SGAMA, por ser um sistema muito complexo, foram utilizados vários diagramas conforme sua necessidade como, por exemplo: diagrama de use case UC, tendo como uma visão mais ampla do sistema, diagrama de sequência onde 1680
se mostram os passos a passo percorridos pelo sistema e diagrama de atividade que apresenta uma visão das atividades ou ações de cada processo até a sua conclusão. 2.2.3 Construção Essa fase é a responsável pela implementação do sistema no ambiente, tendo como objetivo específico codificar os componentes de software e realizar os testes necessários para garantir que aquilo foi definido na fase de concepção de fato foi construído no sistema. A fase de construção está essencialmente relacionada ao projeto, programação e teste do sistema (SOMMERVILLE, 2007). Durante todo o processo do sistema SGAMA, este se encontrava ainda na fase de implementação e implantação, onde os desenvolvedores estão codificando e testando os erros encontrados e acrescentando melhorias no processo de desenvolvimento. 2.2.4 Transição Essa fase final consiste na entrega do sistema pronto com toda documentação necessárias, definindo assim a implantação do sistema e gerenciamento de alguma configuração e mudanças de qualidade futuras. Conforme Sommerville (2007), essa é a fase final do RUP referente à transferência do sistema onde foi desenvolvido para o usuário final, com seu funcionamento no ambiente real. 3 METODOLOGIA Este trabalho iniciou-se a partir de pesquisa bibliográfica, com o objetivo de estudar e analisar o sistema coletando as informações necessárias para um estudo de caso do sistema SGAMA da empresa AGED. Com base nessas pesquisas foi realizado um estudo de caso aprofundado do desenvolvimento do software SGAMA. Para obter esse resultado, foram necessários estudos nas áreas de Engenharia de Software, Engenharia de Requisitos e Modelagem de Software usando UML para elaboração dos diagramas. A metodologia contemplará o levantamento dos requisitos funcionais e não-funcionais utilizando algumas técnicas de requisitos como: a) Entrevista: Esses encontros de entrevista foram realizados na própria AGED com usuários/especialista no negócio e especialistas do SGAMA (desenvolvedores), foram feitas entrevistas fechadas com a veterinária chefa do setor de Epidemiologia e também com os desenvolvedores do sistema, quanto foi importante analisar os problemas de requisitos e a identificação das regras de negócios; b) Questionários: Além da entrevista foi necessário também formular questionários específicos com 13 questões para desenvolvedores do sistema e 13 questões para usuários do negócio, questionários esses aplicados em dia alternados e na própria AGED. 1681
c) Cenários: Onde são descritos as funções do sistema usado na prática, detalhando o fluxo normal dos eventos no cenário. d) Caso de Uso (UC): Foi criado um modelo padrão de formulário para fazer a documentação textual dos UCs, onde serão descritos seus respectivos cenários em consonância com os requisitos identificados. Pela complexidade do sistema houve a necessidade de serem utilizadas todas essas técnicas e aplicadas nessa mesma sequencia indicada com a finalidade da modelagem dos diagramas. 4 PROCESSO DE NEGÓCIOS A AGED Agência Estadual de Defesa Agropecuária do Maranhão é uma autarquia estadual, composta por vários programas da área de defesa animal e vegetal, de onde recebe verbas do Ministério da Agricultura, Pecuária e Abastecimento MAPA. (AGED, 2013). A AGED possui uma hierarquia de uma Estrutura Operacional. São elas: a) Unidade Central: De acordo com o Decreto 5.741, de 30 de março de 2006, os órgãos executores são responsáveis pela execução das atividades de natureza estratégica, normativa, reguladora, coordenadora e operativa de interesse da União, e também as privativas dos Estados ou do Distrito Federal (BRASIL, 2013). A AGED é o órgão executor responsável na Unidade Federativa do Maranhão; b) Unidade Regional UR: É responsável pela gestão administrativa e operacional de todas as unidades veterinárias locais (UVL), sendo intermediária entre a Unidade Central e as UVLs. A UR deve dispor de uma estrutura adequada para coordenar, administrar e operar suas funções (BRASIL, 2013). A AGED possui 18 unidades espalhadas por todo Maranhão; c) Unidade Veterinária Local UVL: É representada por um espaço geográfico e de administração de um ou mais municípios e escritórios de atendimento à comunidade. Para cada UVL, é obrigatória a presença de um médico veterinário da Unidade Central responsável pela defesa sanitária animal; d) Escritório de Atendimento à Comunidade EAC: É a base física e estrutural presente nos municípios que compõem determinada unidade veterinária local UVL, incluindo o seu escritório sede, sob responsabilidade de um funcionário autorizado do órgão executor de defesa sanitário a animal (BRASIL, 2013). De acordo com a figura 3 é apresentada uma demonstração do mapa do Maranhão, da distribuição das Estruturas Operacionais da AGED com sua devida localização. 1682
Figura 3 Estrutura Operacional da AGED/MA Fonte: (BRASIL, 2009) Na figura 4, é apresentado um exemplo de hierarquia de uma Estrutura Operacional da AGED para melhor entendimento da organização das Unidades Regionais. Figura 4 Exemplo da Estrutura Operacional da UR de São João dos Patos Fonte: (AGED, 2013) 1683
O sistema SGAMA tem como uns dos principais objetivos o preenchimento da ficha de Cadastro de Produtores e Propriedades Rurais exigida pelo Ministério da Agricultura, Pecuária e Abastecimento MAPA, que anteriormente era preenchida manualmente pelos funcionários de cada, Unidade Regional UR, Unidade Veterinária Local UVL e Escritório de Atendimento à Comunidade EAC em sua determinada região. Além dessas informações, é necessário o preenchimento dos dados de vacinação contra febre aftosa e o controle de quantidade de animais vacinados em cada campanha. Anteriormente, todas essas informações eram feitas em planilha do Excel e exportadas para o banco de dados. Em cada campanha, obrigatoriamente, que acontece de 06 em 06 meses no período de maio e novembro anualmente, todos animais da espécie de bovinos e bubalinos deverão ser vacinados contra febre aftosa e comprovados. Essas campanhas vêm reforçar e acompanhar os criadores de animais na vacinação de seus rebanhos, pois isto é obrigatório por lei. Para ser considerado livre da febre aftosa é necessário atingir 90% de rebanhos vacinados e comprovados pelo MAPA (BRASIL, 2005). As vacinas poderão ser adquiridas pelo produtor em qualquer estabelecimento que comercializem produtos de uso veterinário, registrado legalmente e comprovado pelo MAPA. A vacina contra febre aftosa é mais comum em duas espécies de animais: bovino e bubalino ou animais de bipartidos. (LOREDO, 2013). Existem outros tipos de vacina contra raiva, brucelose e outras. Deverão ser vacinados de acordo a necessidade e idade do animal a exemplo de caprinos, suínos, asinino, equinos, muares, ovinos e avícolas. Segundo Programa Nacional de Erradicação da Febre Aftosa PNEFA (BRASIL, 2005). Existem vários tipos atividades de vacinação, Serão apresentadas 4 mais usadas: a)vacinação Compulsória (Obrigatória): É aquela que é realizada pelo produtor durante a campanha; b) Vacinação Oficial (agulha oficial): Realizada pela AGED, responsabilidade pela sua aplicação, onde será cobrado do produtor; geralmente é aplicada por conta de inadimplência ou em áreas de propriedades de grandes riscos; c) Vacinação Assistida: É realizada pelo produtor com o acompanhamento de fiscais de defesa animal e assistentes agropecuários da AGED, em propriedade próxima de lixos ou divisa de outros Estados, onde há muita movimentação do gado; d) Vacinação Fiscalizada: Seu acompanhamento é parcial da AGED, com objetivo de orientar um conjunto de propriedades rurais sobre as práticas da vacinação. Após a vacinação, é obrigatório que todos os produtores rurais façam a comprovação da vacinação preenchendo a declaração de vacinação de seu rebanho apresentando juntamente com a nota fiscal da compra da vacina em qualquer uma unidade da AGED para comprovar que o seu rebanho foi vacinado. A AGED deverá apresentar em cada campanha o relatório por faixa etária de animais (bubalinos, bovinos) vacinados e inadimplentes de cada UR, UVL e EAC, e além dos rebanhos leiteiros e outras espécies. O MAPA exige o relatório final da quantidade de animais bovinos e bubalinos por cada propriedades rurais e por quantidade de produtores e explorações rurais existentes e vacinadas, e o relatório dos tipos de vacinas de cada propriedade. 1684
5 ANÁLISE DOS RESULTADOS E DISCUSSÕES Durante o processo de levantamento dos requisitos utilizando-se a técnica de entrevista e questionários com alguns dos atores, foram identificados os seguintes atores, suas funções e suas responsabilidades com o sistema SGAMA. Foram entrevistados os atores: Técnicos EAC, Chefe Veterinário UVL, Observadores e Administradores do Sistema. Quadro 1 - Atores e suas Funções e Responsabilidades no Sistema SGAMA ATOR FUNÇÃO RESPONSABILIDADES Observador Chefe Veterinário UVL Gestor Regional UR Administrador Técnicos Agrícolas, Auxiliar Administrativo da EAC. Diretor Geral, Coordenador de TI, Diretora de Defesa e Inspeção Animal, Chefe do Setor de Epidemiologia, Chefe do Setor da Aftosa. (Sede) Chefe Veterinários, Técnicos da UVL Gestor Regional Programadores Sistema SGAMA do Adicionar, visualizar, editar, excluir no sistema, cadastro do produtor, proprietário e propriedade e suas explorações e comprovação gerando um relatório da EAC Escritório de Atendimento à Comunidade da qual faz parte. Visualizar os dados cadastrados no sistema e gerar os relatórios gerais de vacinação de cada UR responsável pelas demais unidades. Adicionar, visualizar, editar, excluir no sistema, cadastro do produtor, proprietário e propriedade e suas explorações e comprovação gerando um relatório da UVL Unidade Veterinária Local da qual é atendida. Adicionar, visualizar, editar, excluir no sistema, cadastro do produtor, proprietário e propriedade e suas explorações e comprovação gerando um relatório da UR Unidade Regional, da qual gerencia as UVL e consequentemente as EAC. Cadastrar os usuários e definir as permissões dos usuários; cadastrar município, EAC, UVL, UR. A seguir, serão apresentados na Figura 5 os Requisitos Funcionais de como o sistema se comporta em determinadas situação. Já na Figura 6 são expressos os Requisitos Não-Funcionais, as restrições das funções oferecidas no sistema e na mesma Figura 3 representam-se as politicas, condições ou restrições no processo de execução em uma organização chamada de Regras de Negócios. Então, logo em seguida, com base no Quadro 2, podemos observar como se relaciona cada requisitos e suas RN descritas no sistema SGAMA através do seu código representados nas Figuras 5 e 6. 1685
Figura 5 Requisitos Funcionais do SGAMA Figura 6 Requisitos Não Funcionais e Regras de Negócios do SGMA 1686
Quadro 2 Código do RF, RFN, RN e sua descrição no Sistema SGAMA CÓD. RF CÓD. RN 01 04 02 05 03 06 04 07 05 08 06 09 07 10 08 11 09 12 13 13 DESCRIÇÃO RN O acesso do usuário ao sistema deverá ser cadastrado em seu e-mail e senha-padrão (com mínimo 6 e no máximo 20 caracteres). Cada usuário visualizará o sistema conforme o seu perfil cadastrado, que são 5 perfis: Observador, EAC, UVL, UR, Administrador. O preenchimento do cadastro da pessoa física ou jurídica deve ser conforme como está na ficha de cadastro; caso não possua CPF ou CNPJ, será gerado um código provisório. Cadastro do produtor deve seguir conforme os dados da ficha de cadastro. É necessário fazer a busca de proprietário juntamente com o código de proprietário. Ao cadastrar os dados do município é obrigatório gerar o código padrão do IBGE, conforme cada município. Para o cadastro da exploração cumpre buscar-se o produtor e a propriedade já cadastrados. Para o cadastro das comprovações é obrigatório buscar uma exploração já cadastrada, além de efetuar o somatório de cada espécie de animal (macho ou fêmea) daquela exploração. No cadastro da vacinação exige-se o preenchimento do CNPJ do Laboratório, Número da Nota Fiscal e a Partida, e a data de vacinação deverá ser superior à data da compra e validade da vacina. Ao cadastrar uma EAC, é necessário indicar de qual UVL pertence aquela EAC. CÓD. RNF 01.1 01.2 ---- 02.1 04.1 ---- ---- ---- ---- ---- ---- O processo de modelagem do sistema SGAMA ocorreu após o levantamento dos requisitos funcionais e não funcionais e suas regras de negócios; foram descritos os Use Case (UC) ou também conhecido como cenário, onde se expressam de forma detalhada e objetiva os passos de como o sistema será utilizado na ação do ator e ação do sistema. Os UC s representados a seguir nos mostram todos utilizados no sistema e com seus respectivos atores, conforme acesso no sistema. O termo CADASTRAR será utilizado para indicar as ações de adicionar, visualizar editar e excluir os dados, que são realizados no sistema pelo usuário. Cf. Quadro 3. 1687
Use Case UC 01 UC 02 UC 03 Quadro 3 Relação de Use Case (UC) do SGAMA Login do Usuário Cadastrar do Usuário Buscar Usuário Cadastrar Pessoa Relação de Casos de Uso do SGAMA Descrição do UC UC 2.1 Adicionar Usuário UC 2.2 Visualizar Usuário UC 2.3 Editar Usuário UC 2.4 Excluir do Usuário Atores Administrador; Observador; Administrador Administrador Administrador Administrador Administrador; Observador; UC 4.1 Adicionar Perfil Administrador de Usuário UC 4.2 Visualizar Perfil Cadastrar Administrador de Usuário UC 04 Perfil de UC 4.3 Editar Perfil de Usuário Administrador Usuário UC 4.4 Excluir Perfil de Administrador Usuário UC 05 Cancelar Administrador UC 6.1 Adicionar Pessoa UC 6.2 Visualizar Pessoa UC 06 UC 07 UC 08 Buscar Pessoa Cadastrar Produtor UC 6.3 Editar Pessoa UC 6.4 Excluir Pessoa UC 8.1 Adicionar Produtor UC 8.2 Visualizar Produtor UC 8.3 Editar Produtor UC 8.4 Excluir Produtor 1688
Use Case UC 09 UC 10 UC 11 UC 12 UC 13 UC 14 UC 15 UC 16 Buscar Produtor Cadastrar Propriedade Buscar Propriedade Cadastrar Explorações Buscar Explorações Cadastrar Notas Fiscais Buscar Notas Fiscais Cadastrar Comprovação de Vacinação Relação de Casos de Uso do SGAMA Descrição do UC UC 10.1 Adicionar Propriedade UC 10.2 Visualizar Propriedade UC 10.3 Editar Propriedade UC 10.4 Excluir Propriedade UC 12.1 Adicionar Explorações UC 12.2 Visualizar Explorações UC 12.2.1 Listar Rebanho UC 12.3 Editar Explorações UC 12.4 Excluir Explorações UC 14.1 Adicionar Notas Fiscais UC 14.2 Visualizar Notas Fiscais UC 14.3 Editar Notas Fiscais UC 14.4 Excluir Notas Fiscais UC 16.1 Adicionar Comprovação de Vacinação Atores UC 16.2 Imprimir 1689
Use Case UC 17 UC 18 UC 19 UC 20 UC 21 UC 22 UC 23 Relação de Casos de Uso do SGAMA Descrição do UC Comprovação de Vacinação UC 16.3 Editar Comprovação de Vacinação UC 16.4 Excluir Comprovação de Vacinação Buscar Comprovação de Vacinação Gerar Relatórios Cadastrar Município Buscar Município Cadastrar URs Visualizar UVLs Cadastrar EACs UC 19.1 Adicionar Município UC 19.2 Visualizar Município UC 19.3 Editar Município UC 19.4 Excluir Município Atores Neste documento, o termo CADASTRAR será utilizado para indicar ações, isto é, adicionar, visualizar, editar, excluir os dados, realizados no sistema pelo usuário. Segundo Pressman (2006), os cenários, conhecidos também como caso de uso, descrevem de forma detalhada como o sistema será utilizado. A seguir, serão apresentados alguns dos Casos de Uso (UCs) identificados e modelados para o sistema SGAMA, conforme o Quadro 03 descrito acima. Ressalte-se que todos os UCs identificados no Quadro 03 foram devidamente descritos e modelados, mas que apenas parte deles foi mostrada neste trabalho. 1690
5.1 Identificação dos Casos de Usos Como os Casos de Uso identificados para o sistema SGAMA são muitos, para efeito de exemplificação do sistema modelado, serão apresentados aqui apenas alguns dos Casos de Uso referentes à visão de dois atores do sistema, a saber, o do Chefe Veterinário (UVL) e o do Observador. Deste modo, apresenta-se a seguir o diagrama de Casos de Uso da visão do Chefe Veterinário UVL e todas as EACs por ele atendidos, conforme a figura 7. Figura 7 - Diagrama de Uses Case (UC) na Visão Geral do Chefe Veterinário (UVL) A seguir apresentam-se os demais diagramas da UC abaixo descrita. UC 016.1 Adicionar comprovações de vacinação Descrição: Este caso de uso descreve as etapas que os atores adicionam as comprovações da vacinação. Somente usuários cadastrados no sistema poderão utilizar para autenticar-se no sistema e se logar se [UC 01]; então, o sistema apresenta a Folha de Comprovação de Vacinação a ser preenchida. É necessário, então, que o ator clique em Buscar Exploração [UC 13], e o sistema apresentará os dados do produtor, propriedade e proprietário já adicionados. O ator selecionará os dados desejados e automaticamente o sistema preencherá todos os campos referentes à busca. Então, em sequência, para dar continuidade ao cadastro. 1691
O sistema apresenta o campo de Dados da Vacina Febre Aftosa, onde poderão ser adicionados os dados obrigatório da Nota Fiscais como CNPJ do laboratório, número da nota fiscal e partida. O ator clica em adicionar (tem a função de buscar) ou digita os três campos obrigatórios da nota fiscal. Para o [RF 08], descrito na figura 6, são validadas as informações pelo sistema e consequentemente o ator preenche os demais campos como: doses usadas, data da vacinação, tipo de vacinação (assistida, fiscalizada, oficial, compulsória). Após, serão apresentados os demais campos a serem preenchidos da exploração de cada espécie de animal, onde o ator deverá informar a quantidade de animais existentes se (macho e fêmea), conforme a sua idade entre 0 e 12 meses, entre 13 e 24 meses, entre 25 e 36 meses, acima de 36 meses e serão somados e totalizados automaticamente pelo sistema. O ator preencherá os demais campos da exploração de cada espécie e salvar; o sistema confirmará os dados com a mensagem comprovação salva com sucesso. No diagrama de Atividade, conforme Figura 8, logo em seguida do (adicionar comprovação de vacinação), tem como objetivo de melhorar a visão do funcionamento do sistema SGAMA, conforme os UC descritos anteriormente. Para melhor entendimento podemos perceber a importância em adicionar os dados conforme a quantidade de vacina usada e comprovada como mostra a figura 8. Figura 8 - Diagrama de Atividade "Adicionar Comprovação de Vacinação" 1692
Depois de apresentados os diagramas em suas variadas visões no sistema referente a Adicionar Comprovação de Vacinação, apresentam-se a seguir suas respectivas telas no sistema SGAMA, conforme nos mostra a Figura 9, pois, devido à complexidade desta ação, mais de uma tela foi modelada no sistema para realizar esta funcionalidade. Nela, tem-se a divisão de cada parte do processo de adicionar uma comprovação de vacinação no SGAMA, representados pela numeração em ordem numérica e que já foi descrito anteriormente. Figura 9 - Telas do Adicionar Comprovação de Vacinação 1 2 3 Uma das situações mais frequentes é a necessidade de Adicionar Explorações, cuja responsabilidade no sistema é do Chefe Veterinário da UVL. A seguir, apresenta-se, o diagrama de sequência correspondente a esta funcionalidade que mostra como esse ator interage com o sistema, conforme Figura 11. 1693
Figura 11 - Diagrama de Sequência de "Adicionar Explorações" Na figura 12 apresenta-se a respectiva tela de acesso à funcionalidade Adicionar Explorações. Por ela o usuário poderá buscar produtor e buscar propriedade já existente no sistema definindo assim cada produtor e propriedade daquela exploração. Seu funcionamento é simples. Envolve os seguintes passos: 1 O Chefe da UVL clica em selecionar o produtor; 2 O sistema preenche o campo obrigatório com código e nome do produtor automaticamente conforme como foi selecionado; 3 O Chefe da UVL clica em selecionar propriedade; 4 O sistema preenche o campo obrigatório com código e nome da propriedade automaticamente conforme como foi selecionado; 5 O Chefe da UVL completa os demais campos a serem preenchidos com a área total da exploração, em hectare, e escolhe a situação fundiária (arrendatário, meeiro e outros); 6 O sistema valida as informações e depois exibe a mensagem Exploração salva com sucesso. Caso algum campo obrigatório, marcado com asterisco, não seja informado, o sistema exibirá uma mensagem de alerta ao usuário. 1694
Figura 12 - Tela do Sistema SGAMA " Adicionar Exploração" Fonte: (AGED, 2014) Outra ação muito rotineira nesse sistema é o cadastramento de Pessoa Física ou Jurídica. Entretanto, esta funcionalidade é de responsabilidade do ator Observador. Este ator tem a responsabilidade de analisar e visualizar os dados que foram adicionados e gerar os relatórios referentes aos resultados obtidos em cada campanha de vacinação, além de outras funcionalidades. A seguir, apresenta-se o diagrama de Casos de Uso na visão geral do Observador, conforme a figura 13. Figura 13 - Diagrama de Uses Case (UC) na Visão do Observador 1695
UC 6.1 Adicionar Pessoa Descrição: Este caso de uso descreve as etapas que o ator Observador realiza para poder fazer a ação de adicionar uma nova pessoa física ou jurídica no sistema. Esta funcionalidade é realizada toda vez que se fizer necessário adicionar um novo Produtor no sistema, quer seja ele proprietário quer não. No diagrama a seguir, são representados os passos das atividades desenvolvidas no sistema para a funcionalidade Adicionar Pessoa, conforme a figura 14. Figura 14 - Diagrama de Atividade "Adicionar Pessoa" Em seguida, é apresentada a tela correspondente ao diagrama de atividade Adicionar Pessoa, que, mesmo por ser um simples preenchimento de cadastro, é importante preencher os dados corretamente para um acesso posterior desses dados no sistema, conforme Figura 14. Sua utilização é bastante simples e envolve os seguintes passos: 1 O Técnico, Chefe Veterinário ou Gestor UR solicita adicionar pessoa. [RF 03]; 2 O sistema apresenta os campos a serem preenchidos, conforme descrito por [RF 03.1; RF 03.2; RF 03.3]; 3 O Técnico, Chefe Veterinário ou Gestor UR preenche os campos obrigatórios marcados com asterisco clica em salvar; 4 O sistema valida as informações e mostra a mensagem cadastro salvo com sucesso. No caso de algum campo obrigatório não ser informado, o sistema alertará o usuário sobre o erro. CNPJ ou CPF inválidos ou duplicados não serão aceitos pelo sistema. O sistema permite gerar um código provisório no caso da pessoa não ter um CPF ou CNPJ no momento do cadastro, e isto é uma regra de negócio definida pela AGED-MA. 1696
Figura 14 - Tela do Sistema SGAMA "Adicionar Pessoa Fonte: (AGED, 2014) 5 CONCLUSÃO Neste artigo é demonstrada a importância da documentação para qualquer sistema, utilizando a linguagem padrão da UML como modelo e suporte ao desenvolvimento do sistema. Assim, o presente trabalho apresentou uma forma de melhoria para o sistema SGAMA com base no levantamento de seus requisitos funcionais, não-funcionais, suas regras de negócio e os diagramas da UML. Isto permitiu melhor compreensão do sistema por meio dessa documentação, já que, com a especificação do sistema, tornou-se possível maior controle sobre as futuras versões e mudanças que possam ser implementadas no sistema. Ao mesmo tempo que também subsidia as possíveis correções dos erros bugs que poderão ser ainda detectados no sistema em execução. Nesta pesquisa, conforme proposto, foi analisado todo o cenário do sistema por meio de um estudo exploratório de suas principais necessidades, fazendo-se o levantamento dos requisitos funcionais, não funcionais e regras de negócio, utilizando-se técnicas como entrevistas e questionários. Documentaram-se os casos de uso UCs, por meio de um modelo de artefatos textual e descreveram-se os cenários, elaborando os principais diagramas de funcionalidades desse sistema. O detalhamento dos cenários do sistema complementou os diagramas da UML já abordados, permitindo visão melhor do funcionamento do sistema. Desta forma, a modelagem apresentada expressa uma documentação que visa a garantia da consistência entre as necessidades do usuário e a solução automatizada, a organização, a usabilidade e o controle do sistema. As técnicas de elicitação aplicadas, nas fontes de informação, foram suficientes para coletar e identificar as informações que geraram o documento de requisitos para este sistema. Porém, menciona-se que houve alguns momentos de dificuldade durante o processo de elicitação dos requisitos. Ficaram faltando os requisitos relacionados aos blocos do GTA do menu da SEDE, que foi implementado após o término dessa etapa de 1697
elicitação, causando assim algumas mudanças no sistema, mas que não afetaram os demais requisitos já descritos. Cumpre mencionar que, ao longo da elaboração desse trabalho, houve também algumas mudanças no quadro de funcionários na área de desenvolvimento da AGED, o que acabou por causar demora na etapa de elicitação e implementação do sistema, assim como por ocasionar mudanças constantes no escopo do sistema. O processo de todo trabalho levou um tempo considerado razoável para um sistema tão complexo como SGAMA. Depois de toda modelagem do sistema ficam como sugestão a contínua atualização da documentação gerada, bem como a incorporação de outros diagramas para atendimento das demais visões dos usuários, visando-se garantir o controle, consistência e rastreabilidade das mudanças e dos requisitos, a cada nova necessidade requerida pelo usuário e pelas mudanças naturais na visão do negócio. Como o objetivo do SGAMA é cadastrar os produtores e suas propriedades, controlar os dados de cada campanha de vacinação desses produtores, com os seus respectivos rebanhos, como forma de comprovar a vacinação e considerar aquela propriedade fora de risco da febre aftosa, é necessário maior segurança no sistema, por tratar-se de informações sigilosas. Deste modo, considera-se importante investir nesse aspecto para as futuras versões. Outra sugestão de melhoria seria a inserção de uma forma de localização por meio de GPS dessas propriedades, através de técnicas de geoprocessamento, para obter-se, assim, maior controle dos focos de doenças. REFERÊNCIAS AGED. AGED, 2013. Disponivel em: <http://www.aged.ma.gov.br/aged/>. Acesso em: 18 ago. 2013. AGED, SGAMA: Sistema de Gerenciamento Agropecuário do Maranhão. Disponível em: < http://sga.aged.ma.gov.br/users/login>. Acesso em: 22 outubro de 2014. BRASIL, M. A. P. A. Febre Aftosa. Orientações para fiscalização do comércio de vacinas contra a febre aftosa e para controle e avaliação das etapas de vacinação, 2005. Disponivel em: <http://www.agricultura.gov.br/animal/sanidadeanimal/programas/febreaftosa>. Acesso em: 09 agosto 2014. BRASIL, M. A. P. A. Sanidade Animal. Manual de Legislação: Programas Nacionais de Saúde Animal do Brasil, 2009. Disponivel em: <http://www.agricultura.gov.br/animal/sanidade-animal>. Acesso em: 20 out. 2013. BRASIL, M. A. P. A. Departamento de Saúde Animal. Manual de Padronização, 2013. Disponivel em: <http://www.agricultura.gov.br/arq_editor/file/aniamal/mercadointerno/transito/manua L%20DE%20PADRONIZACAO%2017%200.pdf>. Acesso em: 24 setembro de 2014. BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. Rio de Janeiro: Elsevier, 2007. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML Guia do Usuário. Rio de Janeiro: Campos, 2000. 1698
GUEDES, G. T. A. UML 2: Uma abordagem prática. 2. ed. São Paulo: Novatec, 2011. KRUCHTEN, P. Introdução ao RUP Rational Unified Process. São Paulo: Ciência Moderna, 2003. LOREDO, P. Febre Aftosa. Brasil Escola, 2013. Disponivel em: <http://www.brasilescola.com/doencas/febre-aftosa.htm>. Acesso em: 26 setembro 2014. LIMA, A. D. S. UML 2.3: do requisito à solução. São Paulo: Érica, 2011. MARTIN, J. C. C. Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e UML. Rio de Janeiro: Brasport, 2010. MELO, A. C. Desenvolvendo aplicações com UML 2.2: do conceito à implementação. 3. ed. Rio de Janeiro: Brasport, 2010. OMG. Classification of UML 2.3 Diagrams, 2013. Disponivel em: <http://www.umldiagrams.org/uml-23-diagrams.html>. Acesso em: 06 maio 2013. PRESSMAN, R. S. Engenharia de Software. 6. ed. Rio de Janeiro: McGraw Hill, 2006. SBROCCO, J. H. T. C.. 2011 SCOTT, K. O Processo Unificado Explicado. Porto Alegre: Bookman Editora, 2003. SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: Addison Wesley, 2007. 1699