1 INSTITUTO FEDERAL DO PARAN

DIANDRA AKEMI ALVES KUBO

SOFTWARE QUIMIA GERENCIAMENTO DE ANLISES QUMICAS

PARANAGU 2011

2 DIANDRA AKEMI ALVES KUBO

SOFTWARE QUIMIA GERENCIAMENTO DE ANLISES QUMICAS

Trabalho

de

Concluso

de

Curso apresentado ao curso Tcnico Integrado em

Informtica do Instituto Federal do Paran, como requisito

parcial de avaliao.

Orientador: Hugo Alberto Perlin

PARANAGU 2011

Dedico esse trabalho Deus, que sempre esteve comigo e me ajudou ao longo de toda minha formao acadmica.

4 AGRADECIMENTOS

Deus, pela oportunidade nica de concretizao de mais um sonho. Ao Orientador desse trabalho, Professor MSc. Hugo Alberto Perlin, pelo apoio, pacincia, humor e comprometimento demonstrados, que fizeram esse projeto possvel. Aos meus pais, fonte de apoio incondicional. Aos professores dessa instituio, que contriburam cada um sua maneira para achegada reta final desse curso. Aos demais funcionrios da instituio, que tambm deram suporte minha rotina acadmica. Aos meus amigos, pela compreenso e ouvidos sempre disposio. A todos que fizeram, fazem e sempre faro parte da turma de Informtica 2009, que foram de extrema importncia e tiveram papel ativo em toda jornada de aprendizado do curso. Mas em especial ao Lucas Leite e ao Allison Lindner, que ofertaram todo apoio para a concretizao desse trabalho.

" no problema da educao que assenta o grande segredo do aperfeioamento da humanidade." Immanuel Kant

"O que sabemos uma gota; o que ignoramos um oceano." Newton

"Que os vossos esforos desafiem as impossibilidades. Lembrai-vos de que as grandes coisas do homem foram conquistadas do que parecia impossvel." Charles Chaplin

6 RESUMO

Este trabalho consiste em um projeto acadmico de automatizao dos processos de clculos das anlises qumicas na empresa Archer Daniels Midland. Surgiu devido a problemas no processo rudimentar que estava sendo aplicado na referida empresa, tendo seus clculos e armazenamento de resultados em planilhas eletrnicas, o que no garantia praticidade ou segurana. Primeiramente elucidou-se qual a situao atual neste ambiente onde o projeto-soluo seria implementado, e ento, por meio de um estudo de viabilidade chegou-se a concluso de que a melhor resoluo para o problema seria o desenvolvimento de um software especfico. O projeto do Software tomou como base as etapas de Engenharia do Software. Para a anlise de requisitos, foram feitas entrevistas e questionrios com o cliente. Com base nos requisitos levantados, desenvolveu-se a modelagem do sistema, a qual inclui diagramas da UML bem como do banco de dados. A implementao do projeto foi feita utilizando-se a plataforma Java, juntamente com o framework de mapeamento objetorelacional, e teve seu banco de dados implementado na linguagem SQL. O paradigma de programao escolhido foi orientado a objetos. A empresa tem demonstrado grande satisfao em relao aos resultados que o software-soluo vem oferecendo, principalmente no que se refere segurana dos dados, fcil interao software-cliente e praticidade no processo dos clculos. Palavras-chave: Software QuimiA. Engenharia de Software. Archer Daniels Midland. Banco de Dados.

7 ABSTRACT

This work is an academic project to automate the process of chemistries analysis on the company Archer Daniels Midland. Starts to be development when an old process was being used on the mentioned company, having your calculations and storage of results in electronic plans, which not guarantee safety or agility. Starts with a verification about the actual situation on the environment where the solution-project will be implement, and then, by a viability study, was possible to came a conclusion and the best solution would be development a specific software. For requirements analysis, was make interviews and questions with the client. Based in the requirements, was development a system model which includes a UML and data base diagram. The Java platform on the eclipse mapping object framework was used on the project implementation, and has your data base implement in SQL language. The programming paradigm chooses was object oriented. The company is showing great satisfaction about the results that the solution-software is presenting, and mostly about the data safety, easy interaction between client-software and the patricide to make calculation process. Key Words:Software QuimiA. Software Engineering.Archer Daniels Midland. Database.

LISTA DE ILUSTRAES FIGURA 1 Paradigma em Espiral............................................................................... 19 FIGURA 2 Exemplo de Diagrama de Caso de Uso .................................................... 29 FIGURA 3 Exemplo Diagrama de Classes ................................................................. 30 FIGURA 4 Exemplo Diagrama de Seqncia ............................................................ 31 FIGURA 5 Representao do Modelo Entidade-Relacionamento .............................. 34 FIGURA 6 Diagrama de Caso de Uso QuimiA ........................................................... 45 FIGURA 7 Diagrama de Classes QuimiA ................................................................... 47 FIGURA 8 Diagrama de Sequncia FazerLogin ....................................................... 49 FIGURA 9 Diagrama de Sequncia VerificaAdmin ................................................... 50 FIGURA 10 - Diagrama de Sequncia InserirFuncionario ........................................... 52 FIGURA 11 - Diagrama de Sequncia InserirAnalise .................................................. 53 FIGURA 12 - Diagrama de Sequncia InserirCliente.................................................. 54 FIGURA 13 Diagrama de Sequncia CC_Alt_Cli ..................................................... 56 FIGURA 14 Diagrama de Sequncia CC_Alt_Fun ................................................... 57 FIGURA 15 Diagrama de Sequncia CC_Alt_An ..................................................... 58 FIGURA 16 - Diagrama de Sequncia AlterarCliente .................................................. 60 FIGURA 17 Diagrama de Sequncia AlterarAnalise................................................. 61 FIGURA 18 - Diagrama de Sequncia AlterarFuncinario ........................................... 63 FIGURA 19 - Diagrama de Sequncia RelatorioCliente .............................................. 64 FIGURA 20 - Diagrama de Sequncia RelatorioFuncionario....................................... 65 FIGURA 21 - Diagrama de Sequncia RelatorioPeriodo ............................................. 66 FIGURA 22 Modelo Entidade-Relacionamento QuimiA ............................................. 68 FIGURA 23 Modelo Relacional QuimiA...................................................................... 70 FIGURA 24 - Tela de Login ........................................................................................... 72 FIGURA 25 - Tela Principal ........................................................................................... 73 FIGURA 26 - Tela Anlises ........................................................................................... 74 FIGURA 27 - Tela Funcionrios .................................................................................... 75 FIGURA 28 - Tela Relatrios ........................................................................................ 76 FIGURA 29 - Tela Clientes............................................................................................ 77

9 LISTA DE TABELAS TABELA 1 Classificao de Riscos ............................................................................ 24 TABELA 2 Amostra e Normalidade ............................................................................ 38 TABELA 3 Amostra e Volume Pipeta 1 ...................................................................... 38 TABELA 4 Concentrao Padro e Leitura ................................................................ 38 TABELA 5 Amostra e Volume Pipeta 2 ...................................................................... 38

10 APNDICE A Questionrio de Funcionalidades.............................................................................80 B Estudo de Viabilidade...............................................................................................82

11 SUMRIO

1. 1.1 1.2 1.3 1.4 2. 2.1 2.1.1 2.1.1.1 2.1.1.1.1 2.1.2 2.1.2.1 2.1.2.2 2.1.2.3 2.1.2.4 2.1.3 2.1.3.1 2.1.3.2 2.1.3.3 2.1.3.4 2.1.3.5 2.1.4 2.1.4.1

INTRODUO ..................................................................................... 14 Contextualizao.................................................................................. 14 Justificativa........................................................................................... 15 Objetivo Geral ...................................................................................... 15 Objetivos Especficos ........................................................................... 16 FUNDAMENTAO TERICA ........................................................... 17 Engenharia de Software ....................................................................... 17 Ciclo de Vida de Software .................................................................... 17 Paradigma em Espiral .......................................................................... 18 Mtodos geis ..................................................................................... 19 Anlise de Requisitos ........................................................................... 21 Questionrio ......................................................................................... 22 Entrevista ............................................................................................. 22 Seminrio ............................................................................................. 22 Pesquisa .............................................................................................. 23 Anlise de Riscos................................................................................. 23 Identificao dos Riscos ...................................................................... 23 Projeo dos Riscos ............................................................................ 24 Avaliao dos riscos ............................................................................ 24 Gerenciamento e Monitorao dos Riscos .......................................... 24 Estudo de Viabilidade .......................................................................... 25 Orientao a Objetos ........................................................................... 25 Conceitos ............................................................................................. 26

12 2.1.4.2 2.1.4.2.1 2.1.4.2.2 2.1.4.2.3 2.1.4.2.4 2.1.5 2.1.5.1 2.1.5.2 2.1.5.3 2.1.6 2.1.7 2.1.7.1 2.1.7.1.1 2.1.7.1.2 2.1.7.2 2.1.7.3 3. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 Princpios ............................................................................................. 26 Abstrao ............................................................................................. 26 Herana ............................................................................................... 27 Polimorfismo ........................................................................................ 27 Encapsulamento .................................................................................. 27 Modelagem de Dados Orientada a Objetos ......................................... 27 Diagrama de Caso de Uso ................................................................... 28 Diagrama de Classes ........................................................................... 29 Diagrama de Sequncia ....................................................................... 30 Plataforma Java ................................................................................... 31 Banco de Dados................................................................................... 32 Modelo Entidade- Relacionamento (MER) ........................................... 33 Entidades ............................................................................................. 33 Relacionamentos ................................................................................. 33 Modelo Relacional (MR) ....................................................................... 35 SQL ...................................................................................................... 35 METODOLOGIA .................................................................................. 37 Questionrio de Requisitos .................................................................. 37 Anlise de Requisitos........................................................................... 39 Diagrama de Caso de Uso ................................................................... 44 Diagrama de Classes ........................................................................... 45 Diagramas de Sequncia ..................................................................... 48 Diagrama do Modelo Entidade-Relacionamento .................................. 67 Diagrama do Modelo Relacional .......................................................... 69 Ferramentas Utilizadas ........................................................................ 70

13 3.8.1 3.8.2 3.8.3 4. 5. Astah .................................................................................................... 71 BrModelo .............................................................................................. 71 DBDesigner 4 ....................................................................................... 71 RESULTADOS OBTIDOS ................................................................... 72 CONCLUSO ...................................................................................... 78

REFERNCIAS............................................................................................................78 APNDICES.................................................................................................................80

14

1. INTRODUO 1.1 CONTEXTUALIZAO

Na empresa Archer Daniels Midland - ADM, situada na cidade de Paranagu, so produzidos fertilizantes minerais para uso em culturas variadas. Para esse feitio, importante que haja o controle de qualidade da matria-prima e do produto final os prprios fertilizantes. O controle de qualidade dividido em duas partes: anlises qumicas e anlises fsicas. A situao atual na empresa Archer Daniels Midland, na parte do controle de qualidade, a seguinte: primeiro, h o recebimento da matria-prima e do produto final que se chegou a partir do mesmo, que nesse caso so os fertilizantes. Para se fazer o controle da qualidade de ambos, so necessrias duas etapas: as anlises fsicas e as anlises qumicas. Tudo comea com a definio do pedido do cliente: o cliente quem define as propores de Nitrognio (N), Fsforo (P) e Potssio (K) que o fertilizante desejado ter. Ento cada matria-prima passa separadamente pelas anlises fsicas que consistem em fazer sua granulometria - medio do tamanho dos grnulos - e o teste de dureza dos gros, que compara a qualidade dos mesmos. Logo aps, feita uma anlise qumica na qual se verificam as quantidades de NPK somente na matria prima. Com esses dados, possvel colocar as vrias matrias-primas nos dosadores, de acordo com a proporo pedida pelo cliente, formando o fertilizante granulado (adubo). Do produto final, so retiradas amostras que passaro novamente por analises fsicas e qumicas, a fim de se verificar a porcentagem do NPK no produto final, que deve ser de acordo com o pedido do cliente. Os clculos utilizados so todos feitos lanando os dados em planilhas do Excel, na qual aps a obteno dos resultados so lanados para um boletim, que tambm uma planilha eletrnica, para que seja feito o laudo, e seqencialmente a impresso

15 do mesmo, juntamente com o certificado da anlise. Os resultados, ento, ficam todos salvo separadamente em planilhas. Portanto, assim que se chega ao resultado da qualidade do produto. Aps tudo isso, os relatrios so salvos, para posteriormente, serem gerados os relatrios separadamente, de forma rudimentar.

1.2

JUSTIFICATIVA

Com o avano da tecnologia, uma grande quantidade de recursos que facilitam a vida e o trabalho dos seres humanos so criados. Ao mesmo tempo, as empresas pblicas e privadas tem a latente necessidade de automatizar o mximo possvel suas rotinas de trabalho. O desenvolvimento de softwares voltados para a informatizao de estabelecimentos ou para realizar tarefas simples do cotidiano vem se tornando cada vez mais comum, ao mesmo passo que mais utilizado. Na empresa Archer Daniels Midland, na rea das anlises qumicas, o controle de dados feito por meio de vrias planilhas eletrnicas. Elas podem ser muito teis, porm como se trata da utilizao para realizar clculos, elas no so to vantajosas, pois qualquer um pode facilmente alterar o clculo ou alguma varivel que seja constante. Tambm a segurana dos dados fica comprometida, pois fcil o processo para excluso das mesmas. No quesito praticidade, o processo utilizando planilhas eletrnicas novamente mostra-se ineficiente, e deixa uma margem maior ao erro. Portanto, a soluo do projeto com Software QuimiA facilitaria a rotina de trabalho na empresa na parte das anlises qumicas, promovendo mais praticidade e segurana.

1.3

OBJETIVO GERAL

Pretende-se criar um software que auxilie o processo de anlises qumicas de fertilizantes, com base nos processos definidos pela empresa ADM.

16 1.4 OBJETIVOS ESPECFICOS

- A partir da insero de dados das anlises qumicas, o software ir calcular o ndice de normalidade de cada teor (Nitrognio, Potssio, Fsforo), ou seja, far o clculo dos teores; - Cadastrar funcionrios e clientes; - A partir dos resultados das anlises, gerar relatrios peridicos. (dirios, mensais, anuais); - Gerar relatrios de anlises por funcionrio e por cliente; - Fazer um controle de qual funcionrio cadastrou cada anlise, por meio de um sistema de login e senha.

17 2. FUNDAMENTAO TERICA

2.1

ENGENHARIA DE SOFTWARE

Para entendermos melhor o que a Engenharia de Software, primeiramente devemos entender o significado de cada palavra. Segundo Rezende (1999), Engenharia toda construo baseada no conhecimento cientfico. Ele ainda afirma que Software, um subsistema de um sistema operacional, ou seja, um programa de computador. A Engenharia de Software compreende o processo de construir o software da melhor maneira possvel, baseada em estudos. Assim como Martin e McClure (1992) afirmaram, preciso dividir-para-conquistar, que o princpio de que quando temos um problema grande, devemos divid-lo e resolv-lo por partes. Esse tambm o princpio da Engenharia de Softwares. Pode-se divid-la em trs elementos: mtodos, ferramentas e procedimentos. Os mtodos so as tarefas necessrias para se construir o projeto. As ferramentas apiam a execuo das tarefas, automatizando parcial ou completamente. E os procedimentos, constituem-se da relao dos mtodos e das ferramentas, organizando os processos para a construo do software. (PRESSMAN, 1995) Dos vrios mtodos executados com apoio de ferramentas por meio de procedimentos, pode-se chegar a vrias sequncias para a execuo dos mesmos, divididas em etapas. Primeiramente devemos entender quais so as etapas e em que sequncia podem ser executadas, para posteriormente analisarmos cada etapa detalhadamente.

2.1.1 Ciclo de Vida de Software

A construo de um software no apenas ligada sua implementao em si, envolve tambm vrias outras etapas que constituem um ciclo de vida do software.

18 A etapa de planejamento do software ocorre quando a idia geral dele surge, e comea-se a dar molde ao mesmo, pensando nos objetivos gerais. J a anlise de requisitos, quando feito um afunilamento dos objetivos coletando as informaes com o cliente, para melhor entendimento do desejado funcionamento do software. O projeto do software construdo por meio da modelagem do sistema, para que se possa entender as funcionalidades do software, bem como sua arquitetura e estrutura de dados. A codificao a etapa do desenvolvimento do cdigo fonte do software, que deve traduzir o que estava no projeto do mesmo. Os testes comeam aps a codificao, e servem para verificar tanto a parte lgica interna do programa, quanto a parte externa, que diz respeito a interao do cliente com o software. E a manuteno, que so as mudanas que eventualmente ocorrem no software, visando melhor-lo. (PRESSMAN, 1995) Essas so as etapas genricas, presentes na maioria dos paradigmas de ciclo de vida. Como Rezende (1999) afirma, o que muda nos paradigmas o nvel de organizao de cada, bem como seus padres.

2.1.1.1

Paradigma em Espiral

O paradigma em espiral relativamente novo em relao aos outros paradigmas, por isso ele tem partes que so semelhantes aos paradigmas em cascata (SOMMERVILLE, 2004) e prototipao (PRESSMAN, 1995), mas tem aspectos no contidos em nenhum desses dois paradigmas mencionados. O diferencial desse paradigma a anlise de riscos. Como afirma Rezende (1999), encontramos quatro atividades bsicas: o planejamento, quando so determinados os objetivos e restries; a anlise de riscos baseada na coleta de informaes do passo anterior, que define a progresso ou no das atividades; a engenharia, que o desenvolvimento de prottipos para o software e a avaliao feita pelo cliente, onde este comunica-se com os desenvolvedores sugerindo modificaes ou no. Ento, havendo a necessidade de mudanas, volta-se ao primeiro passo, e assim por diante, o que leva a um processo em espiral.

19 As vantagens desse paradigma que a cada iterao o software fica mais completo, correspondendo melhor s expectativas do cliente, que tambm entende mais os riscos. Porm, tambm nota-se que se em uma iterao o avaliador no identifica um risco, ou no o avalia devidamente, posteriormente problemas srios podem ocorrer. Outra problemtica, que o processo pode ser muito longo, com muitas iteraes, at que tenha que ser encerrado. (SOMMERVILLE, 2004, p. 39)

FIGURA1 Paradigma em Espiral

Alm disso, o modelo espiral serviu de base para processos iterativos e incrementais (...) como os Mtodos geis. (SATO, 2007)

2.1.1.1.1 Mtodos geis

Assim como afirmou Larman (2005), no possvel descrever exatamente o que um mtodo gil, mas de modo geral, consideramos os mtodos que tem iteraes curtas com tempo limitado, e com constante evoluo nos planos e requisitos. Esses mtodos so muito evidentes pois na maioria das vezes as coisas no saem como planejado e mudanas necessitam serem feitas enquanto est ocorrendo a codificao do software. Pois quando o cliente comea a observar o projeto virando cdigo, comea a especificar melhor o que realmente quer, uma vez que muito trabalhoso e difcil especificar exatamente o que se quer desde o incio do projeto.

20 Portanto, nota-se a importncia e eficincia dos mtodos geis, que acabam no fim das contas economizando tempo, uma vez que melhor identificar um problema e resolvlo, do que terminar o projeto, e ento identificar todos os problemas. (SATO, 2007) Dos mtodos geis, como RAD, DSDM, UP, RUP e etc., o que foi responsvel por popularizar a categoria, foi o XP, ou Programao Extrema ( Extreme Programming).

- Programao Extrema ou XP

Esse mtodo gil gerou muitas indagaes quando comeou a ser utilizado e popularizado, pois como o nome diz, extremista, e surgiu contrariando vrios aspectos da Engenharia de Software considerados que at ento eram considerados dogmas. A XP tem 4 princpios bsicos: comunicao, feedback, simplicidade e coragem. (SATO, 2007)

- Comunicao Assim como afirma Beck (1999), a maioria das falhas que podem ocorrer em um projeto, so causadas pela falta de comunicao entre as partes envolvidas nele. A comunicao deve fluir durante todos os processos do projeto, que na verdade so impossveis de serem realizados sem a comunicao. A comunicao deve ocorrer tanto quanto de desenvolvedor para desenvolvedor, quanto de cliente para desenvolvedor.

-Feedback Entender o que o cliente realmente quer pode ser a parte mais dificultosa do processo da construo de um software. O XP organizado em ciclos curtos de feedback, para que o cliente possa analisar se o que est sendo feito correto ou se ele deseja algo a mais. Assim, os erros so ligeiramente reparados e futuro grandes erro evitados. (TELES, 2005)

21

-Simplicidade A simplicidade deve estar em tudo. Quanto mais simples a estrutura de um software, mais fcil ser corrig-lo caso seja descoberto um erro no futuro. A simplicidade no projeto melhora a comunicao e o feedback, uma vez que melhor falar sobre algo simples. (BECK, 1999)

- Coragem Teles (2005), afirma que ambos os lados de um projeto desenvolvedores e clientes -, tem seus prprios medos em relao ao que pode acontecer. Esse ltimo fator do XP, afirma que as equipes XP devem lidar com as inseguranas de maneira corajosa, acreditando que os mtodos XP iro dar certo. Extreme Programming um mtodo direto, que valoriza o desenvolvimento do software, e que funciona para equipes de desenvolvimento de qualquer tamanho, como afirma Sato (2007), o que mostra que uma prtica fcil. Um dos quatro princpios da Programao Extrema a comunicao entre as partes envolvidas no projeto, que pode ser feita por meio da anlise de requisitos.

2.1.2 Anlise de Requisitos

Essa a primeira etapa de fato, para a construo do software. ela que comea a dar idias da delimitao do software. importante para o construtor do software saber o que, como, para que e tantas outras indagaes a respeito do software, bem como um construtor de uma casa precisa saber como os futuros moradores querem que a mesma seja, assim como sobre quais fundamentos ela estar baseada, como garantia de satisfao futura dos clientes. ( RUMBAUGH etal., 1994) Utilizando-se da definio do dicionrio, temos que um requisito uma condio indispensvel; exigncia(DICIONRIO AURLIO, 2011). J a palavra anlise definida por Exame minucioso de uma coisa em cada uma das suas partes (DICIONRIO AURLIO, 2011). Ento podemos afirmar que a anlise de requisitos o processo de examinar quais so as exigncias que o software precisa atender.

22 A anlise de requisitos permite identificar quais sero as funes do software, bem como suas interfaces e estruturas. por meio dela que podemos construir prottipos para planejar os modelos de processo do software. (PRESSMAN, 1995) Para uma anlise dos requisitos, podemos faz-la de quatro modos diferentes.: Questionrio, Entrevista, Seminrio e Pesquisa, como props Rezende, (1999, p. 168).

2.1.2.1

Questionrio

quando comea a especificao do sistema, porm de forma bem abrangente. Como o prprio nome descreve, se d por meio de um questionrio, preparado em formulrio, com perguntas sobre o que se pretende com o software, e quais so as necessidades que ele precisa atender.

2.1.2.2

Entrevista

Na entrevista pode-se usar o questionrio como base para as perguntas que sero feitas ao cliente, de maneira a esclarecer o que ficou ambguo. importante que o(os) entrevistador(es) tenha um objetivo em mente sem deixar que fique algum assunto sem o devido esclarecimento, e que o entrevistado seja sempre instigado falar.

2.1.2.3

Seminrio

Pode ser chamado tambm, de reunio de pauta, deve ocorrer entre vrias pessoas de diferentes reas do projeto, para lidar com a relao entre elas, que afetar muito a interao com o software.

23 2.1.2.4 Pesquisa

A pesquisa seria a parte da comprovao dos resultados que se chegaram na anlise, o que Pressman (1995) chamaria tambm de reviso. a pesquisa que define se os requisitos desejados so viveis e no possuem tendncia a atrair futuros problemas, o que nos leva a outra etapa: a anlise de riscos.

2.1.3 Anlise de Riscos

Para o processo de planejamento do software, essencial que exista a tentativa de prever futuros problemas, que so os riscos existentes no projeto. A identificao desses riscos feita na anlise de riscos, bem como o tratamento e possivelmente sua resoluo. Existem algumas etapas na anlise de riscos, que veremos a seguir. Segundo o dicionrio (DICIONRIO AURLIO, 2011), risco um Perigo; inconveniente. Portanto na anlise de riscos precisa-se identificar quais so os perigos no projeto, que podem ser um inconveniente no futuro. Segundo Pressman (1995),existem basicamente trs tipos de riscos: os riscos de projeto, que so relacionados ao cronograma, equipe, aos clientes e etc; riscos tcnicos, que tem a ver com a implementao do software, seu projeto, sua interface e assim por diante; e os riscos de negcio, que so os riscos de venda - como por exemplo um software bom, porm que no apresenta utilidade relevante - , riscos de no ter um software atualizado e etc.

2.1.3.1

Identificao dos Riscos

Para identificar-se os riscos, existem vrias tcnicas, como a reviso da documentao, na qual procura-se por ambiguidades, conflitos de idias/interesses e tambm busca-se a certificao de que os objetivos so plausveis de serem cumpridos no tempo cronogramado. Tambm a entrevista com o pessoal envolvido no projeto, para sanar todas as dvidas, em que haja uma troca de informaes uma tcnica.

24 Uma reviso dos riscos que influenciaram projetos passados tambm importante, para que se tenha uma base e para que erros antigos no se repitam.(RIOS, 2005)

2.1.3.2

Projeo dos Riscos

Nessa etapa, os riscos so classificados. Analisa-se o seu impacto e qual a sua probabilidade de ocorrer.(PRESSMAN, 1995,)

2.1.3.3

Avaliao dos riscos

Tendo a probabilidade e o impacto do risco, podemos chegar a um nvel do risco. Na tabela 1 a seguir, observamos a relao entre probabilidade de ocorrncia x impacto. As clulas em cinza mostram quando o nvel do risco alto. (RIOS, 2007)

Impacto causado no negcio pelo risco Alto Mdio Baixo Alta

Probabilidade de Ocorrncia do Risco Media AltoMedia MedioMedia BaixoMedia Baixa AltaBaixa MedioBaixa BaixoBaixa

AltaAlta MdioAlto BaixoAlto

TABELA1 Classificao de Riscos

Segundo Pressman(1995), nessa etapa, alm da classificao do nvel de cada risco, devemos tambm observar se existe algum relacionamento entre os riscos.

2.1.3.4

Gerenciamento e Monitorao dos Riscos

Essa etapa se finda apenas quando o projeto se finda, pois constante e contnua. Novos riscos podem surgir, alguns podem deixar de existir, o nvel dos riscos existentes pode aumentar ou diminuir, enfim, vrias coisas podem acontecer.

25 Portanto, uma reviso de todos os riscos deve ser feita periodicamente, a fim de que se tenha um monitoramento melhor e conciso de futuros problemas.

2.1.3.5

Estudo de Viabilidade

O projeto do software pode ser muito bom, porm o tempo para entreg-lo em plena funcionalidade pode ser pouco. Ou o software pode ser revolucionrio, mas necessitar de muitos investimentos. Por isso necessrio que antes que todo projeto se inicie, uma verificao se o projeto vivel ou no. Essa a funo do estudo de viabilidade. (REZENDE, 1999) Primeiramente, deve-se chegar a uma concluso de quais so os problemas no ambiente em que o software dever ser implantado. Tambm deve ficar claro qual a situao atual, ou seja, como o procedimento que tenta resolver o problema ou resolve-o. Isso importante pois posterior todo o estudo de viabilidade, o resultado pode ser de que o software no necessrio no ambiente em questo. Com o problema apresentado, as alternativas de soluo para o mesmo so apresentadas, entre elas, a de continuar tratando o problema do modo atual, que pode ser o mais eficaz. Aps isso, a alternativa escolhida depois de uma anlise mostrada. Seus recursos e custos, riscos e benefcios tambm so apresentados. Ento deve-se mostrar qual o objetivo geral e os objetivos especficos da alternativa escolhida. Outra parte importantssima do estudo de viabilidade a apresentao do cronograma desejado pelo cliente, que tambm deve ser analisado para obter-se a resposta se vivel ou no. O estudo de viabilidade faz parte tambm da documentao essencial um projeto de software. (PRESSMAN, 1995)

2.1.4 Orientao a Objetos

Quando se fala em orientao objetos, existem vrias divergncias sobre suas definies. Segundo Pressman (1995), um paradigma orientado objetos

baseado em conceitos como objetos, atributos, classes e membros. Para melhor

26 entendimento, necessrio o uso de coisas do mundo real, pertencentes ao nosso cotidiano.

2.1.4.1

Conceitos

Utilizando-se de um exemplo de um automvel, podemos dizer que um automvel de modelo X um objeto, pois um objeto qualquer coisa real ou abstrata. X tem vrias caractersticas, como ano de fabricao, cor, placa etc. As caractersticas de um objeto podem ser definidas como seus atributos. Continuando no exemplo, X cheio de funcionalidades, como ligar, andar, trocar de marcha etc. Essas funes podem ser chamadas de mtodos do objeto X. O exemplo X um automvel, automvel seria a classe de X, pois uma classe uma implementao de um tipo de objeto. Uma automvel (classe) tem uma estrutura, que tem seus mtodos e atributos. Todos os objetos de uma mesma classe tero os mesmos atributos e mtodos, porm o valor dos mesmo o que os diferenciar. Por exemplo, um automvel de modelo X de cor preta e do ano 1998, enquanto outro de modelo Y de cor vermelha e foi fabricado no ano 2000. Ambos os carros (objetos) tem um modelo, cor e ano de fabricao, porm os valores desses atributos so diferentes. (REZENDE, 1999, p. 191-192)

2.1.4.2

Princpios

Existem basicamente quatro princpios da orientao a objetos: Abstrao, Herana, Polimorfismo e Encapsulamento.

2.1.4.2.1 Abstrao

Rezende (1999, p.192) acredita que na orientao objetos, possvel que se crie seu prprio tipo de dados. Portanto cabe abstrao do desenvolvedor definir quais tipos de dados ele utilizar no seu software.

27 2.1.4.2.2 Herana

A herana ocorre quando criada a partir de uma classe existente, uma nova classe que ser denominada de classe-filha. Essa classe filha herdar todos os mtodos e atributos da sua classe-me, o que vantajoso j que o cdigo reaproveitado. A classe-filha poder ter novos atributos e mtodos.

2.1.4.2.3 Polimorfismo

O polimorfismo est ligado herana. Em uma classe-filha, um mtodo proveniente de sua classe-me pode ser reimplementado. Isso facilita quando se necessrio chamar um mtodo de uma determinada classe com vrias classes-filhas, que agem de maneira diferente porm implementam o mesmo mtodo.

2.1.4.2.4 Encapsulamento

O encapsulamento define que os atributos e mtodos de cada classe tem um nvel de acesso. Eles podem ser do tipo pblico, que significa que qualquer objeto de qualquer classe pode acessar a informao; protegido, que denota as informaes s podero ser acessadas por objetos da mesma classe ou de uma subclasse; e o tipo privado, que quando as informaes dos atributos e mtodos s podem ser acessadas por objetos pertencentes mesma classe. (GUEDES, 2004, p. 41)

2.1.5 Modelagem de Dados Orientada a Objetos

Na modelagem de dados so feitos modelos que permitem o entendimento do que ir ser construdo. Esses modelos nos ajudam a ter uma base para o projeto, bem como um ponto de foco para a reviso do mesmo. Entendemos melhor a informao, as funcionalidades e o comportamento do sistema. (PRESSMAN, 1995, p. 249) E para que se construssem modelos que fossem de entendimento global, foi criada a UML, Unified Modeling Language, que uma linguagem-padro para a

28 elaborao da estrutura de projetos de software. Ela serve basicamente para visualizar, especificar, construir e documentar ao artefatos de um sistema de software. (BOOCH, RUMBAUGH, JACOBSON, 1999) Porm no apenas para grandes sistemas de software, a UML tambm serve para modelar fluxos de trabalho, estrutura e comportamento de sistemas de sade, projetos de hardware, servios bancrios, transportes, vendas e tantas outras opes, bem como afirmou Booch, (1999). Assim como afirma Guedes (2004), a UML composta por vrios diagramas. Um diagrama um conjunto de elementos grficos que representam o funcionamento do sistema sob determinada viso.

2.1.5.1

Diagrama de Caso de Uso

Como afirma Booch (1999, p. 95) um diagrama de caso de uso pretende mostrar a relao entre os casos de uso e atores, o que possibilita um melhor entendimento das funcionalidades do programa, at mesmo para o cliente. Ele feito geralmente na fase de levantamento de requisitos, porm usualmente consultado durante todo o processo do projeto. Como observamos na Figura 2, os atores so representados por bonecos, e podem ser desde um usurio at outro sistema que interaja com o sistema em questo. Um ator interage de alguma forma com o software por meio dos casos de uso. Um caso de uso representado graficamente por um crculo achatado, e significa uma funcionalidade do software.(GUEDES, 2004, pg. 26) Os relacionamentos de associao entre os casos de uso tambm podem ser <<include>> ou <<extend>>. <<Include>> significa que o relacionamento entre os casos de uso ter que acontecer, a o <<extend>> deixa aberto possibilidade. (BOOCH, 1999, p. 372)

29

FIGURA2 Exemplo de Diagrama de Caso de Uso

2.1.5.2

Diagrama de Classes

Um diagrama de classes mostra um conjunto de classes, interfaces, controles e o relacionamento dos elementos citados entre si. Esse tipo de diagrama serve para mostrar o funcionamento esttico do software.(GUEDES, 2004) Em cada elemento, seus atributos e mtodos so mostrados. A respeito dos relacionamentos, eles podem ser de dependncia, generalizao ou associao. Na figura 3, observamos um diagrama de classes com cinco classes, onde <Item> uma agregao de <Pedido>, ou seja, o <Item> faz parte do <Pedido>. Tambm observa-se que existe uma relao de associao entre <Item> e <Produto>, que significa em os objetos dessas duas classes iro se relacionar. E por fim, as classes <SoftwareProduct> e <HardwareProduct> tem um relacionamento de dependncia com a classe <Produto>, os seus atributos e mtodos so os da prpria classe adicionados aos da classe <Produto>.

30

FIGURA 3 Exemplo Diagrama de Classes

Essas relaes de generalizao, associao e dependncia so as mais presentes nos diagramas de classe. As classes que representam Interfaces ou Controles apresentam uma tag identificando-as.

2.1.5.3

Diagrama de Sequncia

Um diagrama de sequncia mostra as interaes entre os objetos e os seus relacionamentos, bem como as mensagens trocadas entre eles. A principal caracterstica que essas informaes so mostradas de acordo com uma linha de tempo. (GUEDES, 2004) Segundo Booch, (1999), esse diagrama utilizado para se ter uma anlise dinmica do sistema. Porm, devemos levar em considerao que apenas um diagrama de sequncia dificilmente cobrir todas as funcionalidades de um software, por isso geralmente vrios diagramas de sequncia so utilizados para apenas um software.

31 Nele esto presentes os atores, objetos, seus vnculos e suas mensagens. Considerando um plano cartesiano, os objetos ficam no eixo X, e cada objeto possui sua linha de vida. As mensagens trocadas entre os objetos ficam no eixo Y. A seqncia dos acontecimentos no eixo X da esquerda para a direita, e no eixo Y, de cima para baixo, como mostra a Figura 4.

FIGURA4 Exemplo Diagrama de Seqncia

2.1.6 Plataforma Java Assim como Rezende (1999) definiu, uma linguagem de p rogramao um veculo de comunicao entre os seres humanos e os computadores. Java uma linguagem de programao orientada a objetos. O Java surgiu em meio ao projeto Green da empresa Sun Microsystems, em dezembro de 1990. Durante o processo de criao do dispositivo Star 7, cujo objetivo era se comunicar com outros dispositivos, um dos membros do projeto, insatisfeito com o desempenho da linguagem que estava sendo utilizada no projeto at ento no caso, o C++ - , resolveu criar uma nova linguagem. (LEMAY, 2001) A linguagem Java foi baseada na linguagem C++, porm tem vrias diferenas dela. Entre ela podemos citar a utilizao de ponteiros, que est presente em C++ porm no em Java. O tempo de desempenho em Java menor, pois a maioria do

32 processamento ocorre em tempo de execuo, o que diminui o tempo (SCHEPKE; SHWERTNER, s.d.). Lemay (2001) afirma que Java uma linguagem pequena e leve, segura, pois os salvaguardas protegem contra programas que possam corromper o andamento do processo e que apesar de no se afirmar com 100% de certeza, uma linguagem que foi criada para ser neutra e porttil. Quanto ltima afirmao, no pode ser considerada como um dogma levando em considerao que com os avanos tecnolgicos, a tendncia que cada vez mais outras plataformas sejam criadas. O Java, como linguagem de programao, serve para criar softwares. E grandes softwares ter vrias informaes armazenadas, que onde entra aparte de banco de dados.

2.1.7 Banco de Dados

Como Silverschatz (2004) afirma, um banco de dados uma coleo de dados inter-relacionados. Para que esses dados sejam melhor gerenciados, existem os SGBDs, Sistemas Gerenciadores de Banco de Dados. Um SGBD permite ao usurio o acesso, consulta e alterao dos dados armazenados. A vantagem de se utilizar os SGBDs que o usurio tem uma viso abstrata dos dados, que facilita o entendimento de como funciona o armazenamento e manuteno dos dados gravados. (SILVERSCHATZ, 2004) Existem trs nveis que abordam a viso do banco de dados, como acredita Silverschatz (2004, p. 4).So eles o fsico, que descreve como ocorre o armazenamento dos dados; o nvel lgico, que mostra quais dados so armazenados e seus relacionamentos; e o nvel de viso, que no mostra todas as partes do banco de dados, apenas o que necessrio para uma pessoa leiga. Para registrar as informaes de um fato ou de uma realidade, podemos fazer uso de modelos, mostrando assim, a relao entre as informaes. Modelos de banco de dados facilitam a compreenso tanto do usurio quanto do analista. (MACHADO, 2004)

33 Os principais modelos de banco de dados so os modelos Entidade Relacionamento e Relacional.

2.1.7.1

Modelo Entidade- Relacionamento (MER)

Esse modelo, bem como diz o prprio nome, est baseado em dois grupos: as entidades e seus relacionamentos.

2.1.7.1.1 Entidades

Assim como acredita Alves (2004, p. 250), uma entidade o um objeto do mundo real que possui caractersticas que o tornam identificvel e que possui uma existncia independente. Essa existncia pode ser fsica como um carro, uma pessoa, ou conceitual como um servio ou uma disciplina escolar. As caractersticas da Entidade so chamadas de atributos, que podem ser simples, compostos ou multivalorados. Os atributos simples so aqueles que no podem ser divididos, e os compostos so aqueles que contem mais de uma informao. Um exemplo de atributo simples idade, que tem apenas um valor. Um atributo composto seria endereo, que dividido em logradouro, nmero, bairro, cidade, etc. J os atributos multivalorados, so aqueles atributos que necessitam de mais de um valor, por exemplo, o atributo telefone: uma pessoa pode ter dois telefones, tornando assim telefone um atributo multivalorado.(SILVERSCHATZ, 2004, p. 23) Os atributos tambm so especificados por seu tipo (numrico, caractere, data) e por um tamanho, que significa quantos dgitos ele tem.(ALVES, 2004, p. 251) Alves (2004, p.252), acredita que as entidades podem ter um atributo chave, que um atributo que as identificam das demais. Entidades que no tem um atributo chave so chamadas de fracas, enquanto as que tem so chamadas de entidades fortes.

2.1.7.1.2 Relacionamentos

34 Segundo Barbieri (1994), os relacionamentos so associaes entre as Entidades de Dados. Eles representam as ligaes que ocorrem entre as entidades. Pode-se dizer que os relacionamentos so as aes. Por exemplo: entidade aluno <cursa> entidade matria. Um relacionamento pode ocorrer entre uma ou mais entidades. Uma instncia de uma entidade o mesmo que uma ocorrncia da entidade. Utilizando exemplos, se temos uma pessoa cadastrada no banco de dados, dizemos que a entidade <pessoa> tem uma ocorrncia. De acordo com a cardinalidade do relacionamento, ns classificamos o seu tipo. Existem basicamente trs tipos de relacionamentos: Um-para-Um (1:1), que quando uma instncia de uma entidade A relaciona-se apenas com um outra instncia de outra entidade B. Tambm existe o relacionamento Um-para-Muitos (1:N ou 1:*), que quando uma instncia de uma entidade A se relaciona com uma ou mais instncias de uma entidade B. E o ltimo tipo, Muitos-para-Muitos (N:N ou *:*), acontece quando uma instncia de uma entidade A se relaciona com uma ou mais a entidade B, assim como na entidade B, uma instncia pode se relacionar com vrias da entidade B. (ALVES, 2004) Na figura 5 observamos como so representados as entidades,

relacionamentos, atributos e a cardinalidade das entidades em um Diagrama Entidade Relacionamento.

FIGURA5 Representao do Modelo Entidade-Relacionamento

35 2.1.7.2 Modelo Relacional (MR)

O Modelo Relacional derivado do modelo Entidade-Relacionamento, e depende do SGBD escolhido. Esse modelo formado por um conjunto de tabelas que representam tanto os dados quanto a relao entre eles. Cada tabela pode possuir vrias colunas, sendo que cada uma tem um nome nico. Cada coluna representa um atributo. Ento, uma linha de uma tabela formada por um conjunto de valores. A maioria das tabelas tem uma Primary Key, ou Chave-Primria, que um atributo em que seus valores no se repetem na tabela. Pode existir tambm uma coluna que seja um atributo Foreign Key, ou Chave-Estrangeira, que um atributo referenciado de outra tabela.

(SILBERSCHATZ, 2004, p. 60) Portanto, no modelo relacional, entidades, relacionamentos, e em alguns casos alguns atributos multivalorados ou/e compostos do modelo entidade-relacionamento, viram tabelas. Como afirma Machado (2004, p. 182), algumas vantagens do modelo relacional so: independncia dos dados, viso mltipla dos dados, melhor comunicao e entendimento, mais agilidade no gerenciamento das informaes, etc. Para a manuteno de banco de dados, existem linguagens de programao especficas. Dentre elas, uma das mais utilizadas a linguagem SQL.

2.1.7.3

SQL O SQL uma linguagem de consulta estruturada Structured Query

Language. Ela comum para gerenciamento de banco de dados, sendo assim, padronizada para a maioria dos SGBDs. A linguagem SQL de fcil uso para o usurio, por isso conhecida como uma linguagem cliente-servidor. E apesar de ser nomeada uma linguagem de consulta, oferece vrios outros recursos, para modificao e garantia da segurana dos dados. (NOBRE, 2000)

36 Assim como acredita Silberschatz (2004), um banco de dados uma coleo de relaes. E existem comandos que permitem ao usurio perceberam relaes entre os dados. A estrutura bsica de um comando no SQL composta por trs partes: - select: que relaciona os atributos desejados na consulta; - from: mostra onde sero pesquisadas as informaes dos atributos; - where: um filtro para quais informaes sero mostradas. Por meio da linguagem SQL podem ser feitas alteraes de nomes de atributos, tabelas, cruzamento de informaes, somas, funes de agregao, criao de tabelas, excluso de dados e outras inmeras possibilidades. (SILBERSCHATZ, 2004)

37

3. METODOLOGIA

Para a construo do software QuimiA - cujo objetivo resolver os problemas atuais no ambiente que ser implantado foram seguidos alguns mtodos da engenharia de software, citados na seo 2.1. Na metodologia, sero explanados os mtodos que ajudaram a resoluo do problema apresentado.

3.1

QUESTIONRIO DE REQUISITOS

O questionrio de requisitos foi o primeiro contato com os funcionrios da empresa ADM, que possibilitou uma primeira noo de qual seria o escopo do software QuimiA. Foi feita uma entrevista com o Responsvel tcnico do laboratrio, que esclareceu o que precisava em um software, e logo aps, o funcionrio respondeu a um questionrio, no qual as principais funcionalidades do software, foram melhor especificadas. A estrutura do software foi superficialmente definida, sendo apontadas as informaes principais que deveriam ser gravadas: de funcionrios, clientes e anlises. E a principal funo, seria realizar os relatrios das anlises, e no questionrio o funcionrio especificou que o relatrio deveria conter o resultado do clculo dos teores das anlises. A necessidade de relatrios por intervalos de tempo foi apontada, sendo em intervalos dirios, mensais e anuais. Tambm foi especificada a vontade de um relatrio que fosse separado por Funcionrio ou Cliente. O funcionrio tambm informou seu suposto nvel de aprendizagem relacionado softwares computacionais, para que fosse analisado o risco de futuramente haver uma no-adaptao. O funcionrio julgou-se apto novas informaes e modos de aprendizado.

38 Outra informao relevante foi passada por meio de quatro tabelas, representadas pelas tabelas 2, 3, 4 e 5. Elas mostram valores pr-definidos que so de extrema importncia para a realizao do clculo de teores, uma vez que so utilizadas as informaes da anlise para obter outras informaes.
AMOSTRA 2 A 4% 5 A 12% Acima 15% URIA NORMALIDADE 0,1 0,2 0,5 0,5

TABELA2 Amostra e Normalidade

AMOSTRA 5 A 10% 11 A 30% Acima 30%

VOL. PIPETA 10 ml 5 ml 5 ml

VALOR 50 100,00 250,00

TABELA3 Amostra e Volume Pipeta 1

CONC. PADRO 14 15 16 18 20

LEITURA 70 75 80 90 100

TABELA 4 Concentrao Padro e Leitura

AMOSTRA 8 A 18% 20 A 30% KCL 60%

VOL. PIPETA 10 ml 5 ml 5 ml

VALOR 1,25 2,50 5,00

TABELA5 Amostra e Volume Pipeta 2

O questionrio de requisitos feito pode ser visto no Apndice A. Aps o questionrio, foi feita uma anlise dos requisitos obtidos por meio do questionrio.

39

3.2

ANLISE DE REQUISITOS

Na Anlise de requisitos, foi especificada de modo mais detalhado a estrutura do software. A descrio de cada funcionalidade, com seus dados de entrada, de sada, suas aes e atores participantes. Abaixo, verificamos quais foram as funcionalidades definidas. Login o Descrio: Possibilitar a entrada do usurio no sistema atravs de um login e uma senha e identificar se o usurio administrador ou no. o Dados de Entrada: Login e senha. o Dados de Sada: Confirmao ou no do login. o Aes: Verificar no banco de dados se o login j existe e, se necessrio, criar novo login e senha. o Participantes: Usurio, Funcionrio, Administrador Manter Funcionrio o Descrio: Contem as funcionalidades Cadastrar e Alterar Funcionrio. o Aes: O usurio escolhe qual funcionalidade vai executar. o Participantes: Usurio, Administrador e Funcionrio. Cadastrar Funcionrio o Descrio: Realizar cadastro de novo funcionrio. o Dados de Entrada: Nome, cargo, login e senha. o Dados de Sada: os dados de entrada no banco de dados. o Aes: Inserir informaes no banco de dados e confirmar cadastro. o Participantes: Usurio e Funcionrio. Alterar Funcionrio o Descrio: Realizar alterao de funcionrio existente.

40 o Dados de Entrada: Nome, cargo, login e senha. o Dados de Sada: os dados de entrada no banco de dados. o Aes: Alterar informaes no banco de dados e confirmar alterao. o Participantes: Usurio e Funcionrio. Consulta Funcionrio o Descrio: Consulta lista de funcionrios o Dados de Entrada: O cdigo do Funcionrio que se deseja. o Dados de Sada: As informaes do Funcionrio desejado. o Aes: Pedir lista de funcionrios para o banco de dados. o Participantes: Usurio, Administrador e Funcionrio. Manter Cliente o Descrio: Contem as funcionalidades Cadastrar e Alterar Cliente o Aes: O usurio escolhe qual funcionalidade vai executar. o Participantes: Usurio, Administrador Cliente e Funcionrio. Cadastrar Cliente o Descrio: Realizar cadastro de novo cliente o Dados de Entrada: Nome, CPF e endereo. o Dados de Sada: os dados de entrada no banco de dados. o Aes: Verificar se o CPF vlido, inserir as informaes no banco de dados e confirmar cadastro. o Participantes: Usurio, Administrador e Cliente. Alterar Cliente o Descrio: Realizar alterao de cliente existente. o Dados de Entrada: Nome, CPF e endereo. o Dados de Sada: os dados de entrada no banco de dados. o Aes: Verificar se o CPF vlido, alterar as informaes no banco de dados e confirmar alteraes.

41 o Participantes: Usurio, Administrador e Cliente. Consulta Cliente o Descrio: Consulta lista de cliente o Dados de Entrada: O cdigo do Cliente que se deseja. o Dados de Sada: As informaes do Cliente desejado. o Aes: Pedir lista de clientes para o banco de dados. o Participantes: Usurio, Administrador e Cliente. Manter Anlise o Descrio: Contem a funcionalidades Cadastrar e Alterar Anlise o Aes: O usurio escolhe qual funcionalidade vai executar. o Participantes: Usurio, Administrador Cliente e Funcionrio. Cadastrar Anlise o Descrio: Realizar cadastro de nova anlise o Dados de Entrada: A leitura da amostra, a leitura do Padro, a massa, o volume, o fator do H2 , o fator do padro, a diluio, a massa em Mg (Magnsio), o fator de diluio, a concentrao, a normalidade, o volume da Pipeta, o cliente e o funcionrio responsvel pela anlise. o Dados de Sada: os dados de entrada no banco de dados. o Aes: Com os dados de entrada, extrair de tabelas do banco de dados outras informaes da anlise, necessrias para que seja feito o clculo dos teores Nitrognio, Potssio e Fsforo da anlise. Tambm adicionar a informao da data anlise. o Participantes: Usurio, Administrador, Funcionrio e Cliente. Alterar Anlise o Descrio: Realizar alterao de anlise existente o Dados de Entrada: A leitura da amostra, a leitura do Padro, a massa, o volume, o fator do H2 , o fator do padro, a diluio, a massa em Mg

42 (Magnsio), o fator de diluio, a concentrao, a normalidade, o volume da Pipeta, o cliente e o funcionrio responsvel pela anlise. o Dados de Sada: os dados de entrada no banco de dados. o Aes: Com os dados de entrada, extrair de tabelas do banco de dados outras informaes da anlise, necessrias para que seja feito o clculo dos teores Nitrognio, Potssio e Fsforo da anlise. o Participantes: Usurio, Administrador, Funcionrio e Cliente. Consulta Anlise o Descrio: Consulta a lista de anlises o Dados de Entrada: A data da(s) anlise(s) que se deseja(m). o Dados de Sada: As informaes da(s) anlise(s) desejada(s). o Aes: Pedir lista anlises para o banco de dados. o Participantes: Usurio, Administrador e Funcionrio. Relatrio da Anlise o Descrio: Ser o relatrio de cada anlise. o Dados de Entrada: Cdigo da anlise, Data em que a anlise foi inserida, teor de Nitrognio, Potssio e Fsforo. o Dados de Sada: Os dados de entrada no banco de dados. o Aes: Quando uma anlise for inserida, automaticamente ser criado um relatrio especfico dela, que pegar os dados dessa anlise e ir calcular os teores de Nitrognio, Fsforo e Potssio. o Participantes: Usurio e Funcionrio Relatrio Dirio o Descrio: Ser o relatrio de todas as anlises de um determinado dia. o Dados de Entrada: Data desejada. o Dados de Sada: Todas as relatrios de anlises que foram cadastradas no dia requerido.

43 o Aes: Buscar no banco de dados todos os relatrios de anlise com a data desejada pelo cliente. o Participantes: Usurio e Funcionrio Relatrio Mensal o Descrio: Ser o relatrio de todas as anlises de um determinado ms. o Dados de Entrada: Ms e ano desejados. o Dados de Sada: Todas as relatrios de anlises que foram cadastradas no ms e ano requeridos. o Aes: Buscar no banco de dados todos os relatrios de anlise com o ms e ano desejados pelo cliente. o Participantes: Usurio e Funcionrio Relatrio Anual o Descrio: Ser o relatrio de todas as anlises de um determinado ano. o Dados de Entrada: Ano desejada. o Dados de Sada: Todas as relatrios de anlises que foram cadastradas no ano requerido. o Aes: Buscar no banco de dados todos os relatrios de anlise com o ano desejado pelo cliente. o Participantes: Usurio e Funcionrio Relatrio por Cliente o Descrio: Ser o relatrio de todas as anlises de um determinado cliente. o Dados de Entrada: Cliente de anlise. o Dados de Sada: Todas as relatrios de anlises que foram cadastradas para determinado Clente. o Aes: Buscar no banco de dados todos os relatrios de anlise com o cliente desejado. o Participantes: Usurio, Administrador, Funcionrio e Cliente

44

Relatrio por Funcionrio o Descrio: Ser o relatrio de todas as anlises de um determinado funcionrio. o Dados de Entrada: Funcionrio de anlise. o Dados de Sada: Todos os relatrios de anlises que foram cadastradas para determinado Funcionrio o Aes: Buscar no banco de dados todos os relatrios de anlise com o funcionrio desejado. o Participantes: Usurio, Administrador, Funcionrio e Cliente

3.3

DIAGRAMA DE CASO DE USO

O diagrama de caso de uso tem o objetivo de mostrar as funcionalidades gerais do software, bem como visto na seo 2.1.5.1. diagrama de caso de uso do software QuimiA. A funo Manter Cliente ter as subfunes Cadastra Cliente e Consulta Cliente. Essas funes precisaro chamar a funo Consulta Cliente. Essas funes estaro ligadas diretamente ao ator Cliente. J a funo Gerar Relatrio poder ou no chamar as funes Anlises por Cliente e Anlises por Funcionrio, que estaro relacionadas aos atores Cliente e Funcionrio. A funo Manter Anlise, ter as subfunes Cadastrar e Alterar Anlise. Essas funes necessariamente tero que chamar as funes de Consultar Funcionrio, ligada ao ator Funcionrio e Consultar Cliente, ligada ao ator Cliente pois as informaes desses dois atores esto ligadas a informaes das anlises. E ainda, as funes de Manter Anlise precisaram chamar a funo de Consulta Anlise. A funo Manter Funcionrio, associada ao ator Funcionrio, obter as funes de Alterar e Cadastrar Funcionrios, ambas ligadas Consulta de Funcionrios. Na figura 6, podemos observar o

45

Algumas funes no esto diretamente ligadas aos atores, so relacionadas apenas com outras funes. Das funes associadas aos atores, apenas as de alterao no so permitidas ao ator Usurio, somente ao Administrador.

FIGURA6 Diagrama de Caso de Uso QuimiA

Aps a diagramao dos casos de uso, a prxima etapa da engenharia de um software, foi a diagramao das classes.

3.4

DIAGRAMA DE CLASSES

O diagrama de classes, como apontado na seo 2.1.5.2, serve para mostrar o funcionamento esttico do software. O diagrama de classes do software QuimiA pode ser observado na figura 7.

46 No diagrama de classes do QuimiA, alm das classes, foram representadas as persistncias, que fazem a conexo com o banco de dados e as interfaces grficas. A classe Main uma classe de Interface grfica, e ela que permitir o acesso a todas as outras classes. A classe RelPeriodo representa a interface grfica em que ser escolhido o intervalo de tempo que o relatrio precisar corresponder, enquanto Rel_Cli corresponde aos relatrios por cliente e Rel_Func associada aos Relatrios por funcionrio. Todas essas classes esto ligadas uma classe de Controle, Rel_Controle, que faz comunicao entre as Entidades e as Interfaces Grficas. Este, por sua vez, se relaciona com a Classe Relatrio, cujos atributos mostram as informaes necessrias a cada relatrio de anlise. Por isso, Relatrio se relaciona com a classe Anlise, pois um relatrio um relatrio de uma ou mais anlises. Relatrio tambm se relaciona com a classe PerRelatrio que a classe que far a persistncia dos relatrios, alterando informaes no banco de dados. Por outro lado, a classe An_Insere/Altera representa a classe de interface grfica para a insero a alterao de dados de anlises. A interface ser a mesma, dispensando a criao de duas classes. Essa interface se relacionar com An_Controle, que uma classe do tipo controle, que controla as informaes da Anlise, passando para a PerAnalises, que far a persistncia das Anlises. Na anlise, estaro contidas informaes do cliente que solicitou a analise, bem como do funcionrio que a realizou. Por isso, a classe Anlise se relaciona com as classes Cliente e Funcionrio. A classe Cl_Insere/Altera uma interface grfica para inserir e alterar dados dos Clientes cadastrados no software QuimiA. Esta classe se relaciona com Cl_Controle, que faz o controle das informaes que a interface coleta do Cliente, passando-as para a classe PerCliente, na qual ocorre a persistncia dos dados do Cliente para o banco de dados. Um Cliente tem um endereo e um endereo contem muitas informaes. Por isso, ao invs de um mero atributo, Endereo uma outra classe, relacionada a Cliente.

47 E a classe Fun_Insere/Altera associada classe Fun_Controle, que passa as informaes de um Funcionrio para PerFuncionario, que far sua persistncia. Um Funcionrio pode ser um Tcnico ou um Analista. Por esse motivo foram criadas estas duas classes, que so uma especificao de Funcionrio.

FIGURA7 Diagrama de Classes QuimiA

48 Depois de uma viso esttica do sistema, importante que tenhamos uma viso dinmica, obtida pelos diagramas de Sequncia.

3.5

DIAGRAMAS DE SEQUNCIA

Como foi abordado na seo 2.1.5.3, um diagrama de sequncia mostra por meio de uma linha do tempo as interaes entre os objetos e seus relacionamentos, bem como as mensagens trocadas entre eles. A figura 8 nos mostra um diagrama de sequncia do software QuimiA, que apresenta a funcionalidade FazerLogin. O ator <Usurio> chama a interface que ir fazer o login. Aps a insero dos dados na classe Login, a mesma ir chamar a classe controle Fun_Controle, que ir pedir para a classe de persistncia PerFuncionrio verificar no banco de dados se o login e a senha existem. Se o login e a senha estiverem corretos, a interface Main chamada, caso contrrio, o <Usurio> informado do erro.

49

FIGURA8 Diagrama de Sequncia FazerLogin

A seguir, na figura 9, observamos o diagrama de sequncia VerificaAdmin, que demonstra como ocorrer o concesso de permisso para fazer alteraes de cadastros tanto de anlises quanto de clientes e funcionrios, de uma forma geral. Ao interagir com a interface, o <Usurio> passar seu cdigo, que ser passado da interface para a classe Fun_Controle, que faz o controle dos Funcionrios. Fun_Controle vai pedir pra PerFuncionario verificar no banco de dados se o login e a senha esto corretos. Caso estejam, a permisso concedida, o que no acontece caso o login e/ou a senha estiverem incorretos.

50

FIGURA9 Diagrama de Sequncia VerificaAdmin

51 Na figura 10, observamos o diagrama de seqncia da funcionalidade InserirFuncionario. O ator que ir interagir ser o <Usurio>. Assim que a Interface para a criao do Funcionrio chamada, ela pede para a classe Fun_Controle, que a classe controle para mandar qual o prximo cdigo disponvel de um funcionrio. Por sua vez, Fun_Controle faz o pedido pra

PerFuncionario, que verifica no banco de dados qual o prximo cdigo disponvel. PerFucionrioretora o cdigo para Fun_Controle, que retorna para a interface Fun_Insere/Altera, que mostra para o ator <Usurio> qual ser o cdigo do funcionrio a ser cadastrado. Ento o <Usurio> insere os dados do Funcionrio que ser cadastrado na interface Fun_Insere/Altera, que manda os dados pro controle Fun_Controle, quem cria um objeto da classe Funcionario, e manda para PerFuncionrio, que ir tentar inserir os dados no banco. Se o cadastro ocorrer normalmente, uma mensagem de confirmao mostrada para o <Usurio>. Caso contrrio, o <Usurio> informado da falha. Nas figuras 11 e 12, observamos os diagramas de seqncia de InserirAnlise e InserirCliente, que tem basicamente o mesmo funcionamento de InserirFuncionrio. O que os diferencia so as classes, porm o tipo delas no varia.

52

FIGURA10 - Diagrama de Sequncia InserirFuncionario

53

FIGURA11 - Diagrama de Sequncia InserirAnalise

54

FIGURA12 - Diagrama de Sequncia InserirCliente

55

Para a alterao de dados, primeiramente preciso que o usurio seja um <Administrador>, para ter a permisso, como foi mostrado no diagrama de seqnciaVerificaAdmin. Se o usurio administrador, ele pode fazer a alterao, que vai ser representada por dois diagramas, oCC_Alt_Cli e o Alterar Cliente, pois ocorre em duas etapas. A primeira etapa pode ser vista na figura 13.

56

FIGURA13 Diagrama de Sequncia CC_Alt_Cli

A interface Cl_Insere/Altera ir pegar o cdigo do Cliente a ser alterado e ir passar para a classe de controle Cl_Controle. Esta, por sua vez, ir passar o cdigo para PerCliente que ir fazer a verificao da existncia ou no do cdigo no banco de dados. O usurio ir receber a mensagem se foi ou no encontrado o cdigo.

57 O mesmo processo ocorre para a alterao de Funcionrios e Anlises, como observaremos respectivamente nas figuras 14 e 15.

FIGURA14 Diagrama de Sequncia CC_Alt_Fun

58

FIGURA15 Diagrama de Sequncia CC_Alt_An

59

Aps essa etapa de verificao, vem a etapa da alterao em si. Analisando figura 16, podemos ver que se CC_Alt_Cli mostrar que o cdigo est incorreto, a alterao no segue. Caso o cdigo exista, o usurio passa os dados para a interface Cl_Insere/Altera, que ir fornecer esses dados para Cl_Controle. A classe de controle Cl_Controle ir criar um objeto do tipo Cliente, e ir pass-lo para PerCliente, que far a alterao dos dados no banco de dados. Aps a alterao, o usurio ser informado se a mesma ocorreu com sucesso ou no. Nas figuras 17 e 18, mostra-se o mesmo processo para Anlises e Funcionrios.

60

FIGURA16 - Diagrama de Sequncia AlterarCliente

61

FIGURA17 Diagrama de Sequncia AlterarAnalise

62

63

FIGURA18 - Diagrama de Sequncia AlterarFuncinario

64 Na figura 19, observamos o diagrama de sequncia RelatorioCliente. Ele mostra como funciona o processo de gerar relatrios por cliente.

FIGURA19 - Diagrama de Sequncia RelatorioCliente

O usurio passa o cdigo do cliente desejado para a interface Rel_Cli, que ir mandar para Rel_Controle, que tambm enviar esse cdigo para PerRelatorio, que ir retornar uma Array (lista) de anlises que foram feitas para o cliente do cdigo que o usurio especificou. Se o cdigo estiver correto e/ou houver anlises registradas com tal cliente, o relatrio ser exibido ao Usurio. Caso contrrio, ele informado do erro.

65 O relatrio por Funcionrio funciona semelhantemente ao relatrio por Cliente. Como vemos na figura 20, o cdigo do funcionrio passado para a interface Rel_Func, que passa para a classe Rel_Controle, que ir pedir para PerRelatorio verificar no banco quais anlises foram feitas pelo Funcionrio requerido. Se o cdigo for vlido e/ou existirem anlises para tal funcionrio, o relatrio ser exibido para o Usurio, caso contrrio, ele ser informado do erro.

FIGURA20 - Diagrama de Sequncia RelatorioFuncionario

E por fim, temos o diagrama RelatorioPeriodo. Ele representa a funcionalidade de relatrios por determinados perodos de tempo, e est representado na figura 21.

66

FIGURA21 - Diagrama de Sequncia RelatorioPeriodo

O usurio ir passar para a interface Relatrios qual a data inicial e final que ir abranger o relatrio. Essa interface ir passar para Rel_Controle, que ir pedir para PerRelatrio verificar quais so as anlises registradas naquele intervalo de tempo. Se as datas estiverem corretas e existirem relatrios no perodo requisitado, o relatrio ser mostrado ao usurio. Caso contrrio, o usurio ser informado do erro.

67 Depois de uma viso dinmica do sistema, importante que tenhamos uma viso conceitual do software, obtida pelo diagrama do modelo Entidade-

Relacionamento.

3.6

DIAGRAMA DO MODELO ENTIDADE-RELACIONAMENTO

Como mostrado na seo 2.1.7.1, um diagrama do modelo EntidadeRelacionamento, como o nome mesmo diz, visa mostrar as entidades do software e seus relacionamentos. Essa viso tem um nvel de abstrao maior que o do Modelo Relacional, e ambos tem como objetivo representar as informaes no Banco de Dados. Na figura 22, observamos o diagrama do modelo Entidade-Relacionamento do software QuimiA. A principal funo do software QuimiA fazer a manipulao de Anlises que tenham informaes sobre o Cliente que a requisitou e o Funcionrio que a realizou. Por isso primeiramente foram criadas essas trs entidades. Uma Anlise precisa consultar valores pr-definidos para determinar outros atributos seus, como foi mostrado nas Tabelas 2, 3, 4 e 5. Cada tabela dessas virou uma entidade, que so as entidades PotConcentracao,PotAmostra, TabelaFosfe TabelaNitro. Ainda, uma Anlise tem uma Matria-Prima. No modelo entidade-

relacionamento, o que antes era um atributo virou uma entidade para diminuir a redundncia dos dados, em vista que a empresa ADM no tem uma variao muito grande de Matrias-Prima. A entidade Funcionrio se relaciona com Anlise pois na anlise fica registrado quem foi o funcionrio que a realizou. Um Funcionrio pode ser um Tcnico ou um Qumico/Analista. E a Anlise ainda se relaciona com Cliente, pois o Cliente que faz o requerimento de uma Anlise. Um Cliente tem um Endereo, representado por outra entidade por ter vrias sub-informaes. Um Endereo possui uma Cidade, que

68 pertence a um Estado. As entidades Cidade e Estado foram criadas tambm para reduzir a redundncia dos dados.

FIGURA22 Modelo Entidade-Relacionamento QuimiA

E finalmente, precisamos ter uma viso Relacional dos dados, dada pelo Diagramado Modelo Relacional, que o mais prximo de como as informaes realmente ficam no Banco de Dados.

69 3.7 DIAGRAMA DO MODELO RELACIONAL

esse diagrama que define a modelagem lgica do banco de dados. derivado do modelo Conceitual. Ele formado por tabelas e suas ligaes. Na figura 23, vemos o Diagrama do Modelo Relacional do software QuimiA. Todas as Entidades do Modelo Entidade-Relacionamento viraram tabelas, em que os atributos so representados pelas linhas. As relaes de cardinalidade 1:N no modelo Conceitual agora so representadas pelas FKs nas entidades em que a cardinalidade N. Como no haviam relacionamentos entre as entidades de N:N, nenhuma nova tabela precisou ser criada. A nica tabela diferente do modelo conceitual a GLOBAL_2, que contm as variveis globais, que so constantes. Os atributos PKs escolhidos so em sua maioria cdigos que o prprio SGBD gera, facilitando a identificao dos dados.

70

FIGURA23 Modelo Relacional QuimiA

3.8

FERRAMENTAS UTILIZADAS

Algumas ferramentas serviram como apoio metodologia do Software QuimiA.

71 3.8.1 Astah

um software desenvolvido pela empresa AstahCommunity que auxilia na criao de diagramas seguindo as regras da UML. Deu suporte aos diagramas de caso de uso, classes e seqncia. Disponvel em: <http://astah.net/download>

3.8.2 BrModelo

Desenvolvido por Carlos Cndido como Trabalho de Concluso de Curso, um

software que ajuda na criao de diagramas do modelo entidade-relacionamento. Disponvel em: <http://www.baixaki.com.br/download/brmodelo.htm>

3.8.3 DBDesigner 4

fabFORCE.net

desenvolveu

DBDesigner

para

construir

modelos

Relacionais para bancos de dados. Por meio dele pode-se tambm conseguir o cdigo SQL das tabelas.Disponvel em: <http://www.baixaki.com.br/download/dbdesigner.htm>

72

4. RESULTADOS OBTIDOS

O Software QuimiA foi desenvolvido com base nos diagramas e modelos gerados ao deste longo do projeto. Seguindo os conceitos da XP (Extreme Programming), explanados na seo 2.1.1, a cada novo objetivo a ser cumprido, havia um planejamento, anlise de riscos, implementao e avaliao do cliente. O Software foi desenvolvida na plataforma java, por meio da IDE Netbeans. Seu banco de dados foi desenvolvido na linguagem SQL e utilizou o Sistema Gerenciador de Banco de Dados Firebird, por meio da ferramenta FlameRobin. A interface grfica do Software foi desenvolvida com o objetivo de ser simples e direta, facilitando o manuseio do usurio. Na figura 24 observamos a tela incial do Software, a tela de Login.

Figura 24 - Tela de Login

73 Foi definido pelo cliente, que apenas o administrador poderia adicionar funcionrios que tivessem acesso ao software, portanto, se o usurio no possui um login e senha, no pode se cadastrar sozinho, mas apenas por meio de um administrador. Caso o usurio tenha um login e um senha, basta digit-los corretamente nos campos de texto e ento ele poder ter acesso s ferramentas do software. Na figura 25, observamos a tela principal do Software.

Figura 25 - Tela Principal

No rodap da tela, o usurio ver o seu prprio nome escrito. Caso o usurio seja o administrador, essa especificao aparecer tambm. Na parte lateral direita, encontra-se o menu de opes. Foi escolhido um menu que tivesse as opes possveis prximas para facilitar . Na opo Anlises, o usurio poder adicionar anlises, e/ou, se for administrador, alter-las. J na opo Funcionrios ocorrero as aes de adicionar e/ou alterar os registros. Para ambas as funes o usurio deve ser administrador. Seguindo, na opo Relatrios, haver as opes de exibio por: Cliente, Funcionrio ou Perodo.

74 A opo Clientes possibilita o cadastro e alterao de clientes, que podem ser realizados tanto pelo administrador quanto por um funcionrio comum. Na opo Sobre, esto informaes sobre o desenvolvimento do software e contato com os colaboradores. Na figura 26 est a representao da janela de Anlises. As diferenas entre a tela de alterao e a de cadastro de anlises mnima, o que as diferencia que primeiramente deve ser informado o cdigo da anlise, e ento suas informaes aparecem nos seus respectivos campos de texto. A interface simples e intuitiva, os dados que necessitam ser preenchidos tm sua especificao direita.

Figura 26 - Tela Anlises

75 Na figura 27, observamos a tela de Funcionrios. As informaes necessrias devem ser preenchidas nos campos esquerda. Na parte de informar o cargo do Funcionrio a ser cadastrado, foi optado por uma lista, para evitar a redundncia dos dados, levando em conta que so apenas duas as opes vlidas. O login que o usurio inserir tambm deve ser nico. J na figura 28, est a tela de Relatrios. O usurio deve escolher qual modalidade de relatrio deseja ver: se ser um relatrio apenas de determinado cliente; de determinado funcionrio; ou de determinado perodo.

Figura 27 - Tela Funcionrios

76

Figura 28 - Tela Relatrios

77

Na figura 29, est a tela de Clientes. cadastrado/alterado devero ser inseridas.

Nela os dados do cliente a ser

Figura 29 - Tela Clientes

O software foi planejado levando em conta a opinio do cliente, que se mostrou satisfeito com o resultado obtido, uma vez que o mesmo atendeu aos objetivos iniciais. Ao utilizar o software pela primeira vez, o cliente no encontrou dificuldade alguma. Ele aprovou a interface grfica, porm acima de tudo, o bom funcionamento das ferramentas propostas.

78

5. CONCLUSO

A empresa Archer Daniels Midland utilizava mtodos de realizar seus clculos de anlises qumicas um tanto rudimentares, com pouca praticidade e uma segurana dbia. Por meio de um estudo de viabilidade, entrevistas e questionrios, a alternativa mais vivel para a soluo do problema apresentado foi a criao de um software que atendesse as necessidades da empresa. Para chegar-se a um software robusto como produto final, foram estudados os princpios da Engenharia de Software, o que possibilitou um embasamento em uma fundamentao terica concisa. Por meio do software QuimiA resultado final deste projeto o processo de clculos e armazenamento se mostra claramente mais eficiente. O software foi desenvolvido na plataforma Java, tendo como Sistema Gerenciador de Banco de Dados o Firebird. O planejamento do software diagramas e modelos foi feito seguindo a UML. O software QuimiA tem um controle de acesso por meio de login e senha, e uma diferenciao do usurio como administrador ou no. O cadastro e a alterao de anlises, clientes e funcionrios tambm so realizados pelo software, bem como a gerao de relatrios cujas modalidades so definidas pelo usurio. O software desenvolvido foi codificado com a inteno de fcil manuteno, e poder ser facilmente alterado futuramente, conforme a necessidade. Todos os objetivos iniciais foram cumpridos: tanto o objetivo geral criao de um software que atendesse s necessidades da empresa -, quanto os objetivos especficos que definiam as funcionalidades gerais do sistema. O trabalho contribuiu para o aumento dos conhecimentos da autora tanto na parte da escrita acadmica - dedicada a trabalhos formais-, quanto na parte do desenvolvimento do software em que conhecimentos tcnicos precisaram ser explorados.

79 Muitos conceitos abordados no trabalho tiveram uma fundamentao terica mais robusta devido ao conhecimento passado durante o curso pelos professores e, pelo material disponibilizado pelos mesmos. Em suma, por meio deste projeto mais conhecimento foi adquirido. Tanto pelo estudo necessrio para concretiz-lo, quanto pelos desafios que o projeto lanou. Espera-se que o projeto sirva de incentivo a futuras pesquisas.

80 REFERNCIAS PRESSMAN, R. S., Engenharia de Software, 3. ed. SP: MAKRON, 1995. REZENDE,D. A., Engenharia de Software e Sistemas de Informao, 1. ed. Rio de Janeiro, RJ: Brasport, 1999. MARTIN, J; McCLURE, C., Tcnicas Estruturadas e Case, 1. ed.SP: MAKRON, 1992. SOMMERVILLE, I, Engenharia de Software, 6.ed. SP: PEARSON, 2004. LARMAN, C., Utilizando UML e Padres: Uma introduo anlise e ao projeto orientados a objetoe ao desenvolvimento iterativo, 3. ed., SP: BOOKMAN, 2005. SATO, D. T., Uso eficaz de mtricas em mtodos geis de desenvolvimento de software. 139 f. Dissertao (Mestrado em Cincia da Computao) Setor de Matemtica e Estatsticas, Universidade de So Paulo,So Paulo, 2007. Disponvel em: <http://grenoble.ime.usp.br/~gold/orientados/dissertacaoDaniloSato.pdf> Acesso em: 01 jul. 2011. RUMBAUGH, J.; BLAHA, M.; PREMERLANI, W.; EDDY, F.; LORENSEN, W., Modelagem e Projetos Baseados em Objetos, Rio de Janeiro: ELSEVIER, 1994. GUSMO, C. M.; MOURA, H. P., Gerncia de Risco em Processos de Qualidade de Software: Uma Anlise Comparativa, Recife, PE: RIOS, E.,Anlise de Riscos em Teste de Software, 1. ed.,Rio de Janeiro, RJ: ALTA BOOKS, 2005. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I, UML Guia do Usurio, 2. ed. Rio de Janeiro, RJ: CAMPUS, 1999. GUEDES, G. T. A., UML Uma Abordagem Prtica,2. ed., So Paulo, SP: NOVATEC, 2004. LEMAY, L.; CADENHEAD, R., Aprenda em 21 dias Java 2, 1. ed., Rio de Janeiro, RJ: CAMPUS, 2001.

81 SCHEPKE, C.; SHWERTNER, C., Comparao entre Java e C++ na Computao Numrica, Universidade de Santa Maria. TELES, V.;UM ESTUDO DE CASO DA ADOO DAS PRTICAS E VALORES DO EXTREME PROGRAMMING,Dissertao (Mestrado em Informtica) UniversidadeFederal do Rio de Janeiro - UFRJ, Rio de Janeiro, 2005. BECK, K.;Extreme Programming Explained, 1. ed., Los Alamitos, CA, USA, ISSN 0018-9162, 1999. SILVERSCHATZ, A.; KORTH, H.; SUDARSHAN, S., SISTEMA DE BANCO DE DADOS, 3. ed., So Paulo, SP, PEARSON, 2004. MACHADO, F.; ABREU, M., Projeto de Banco de Dados Uma Viso Prtica, 11. ed., So Paulo, SP, RICA LTDA, 2004. ALVES, W.;Fundamentos de Banco de Dados, 1. ed., So Paulo, SP, RICA, 2004. BARBIERI, C.; Modelagem de Dados, 5. ed., Rio de Janeiro, RJ, INFOBOOK LTDA, 1994. NOBRE, M.; InterBase o Poderoso Sistema Gerenciador de Banco de Dados Relacional, 2. ed., So Paulo, SP, RICA, 2000. DICIONRIO AURLIO, Acessado em: 10 de Dezembro de 2011, disponvel em: <http://www.dicionariodoaurelio.com>

82

APNDICE A QUESTIONRIO DE FUNCIONALIDADES

Funcionrio: Milton Kubo

Cargo: Engenheiro Qumico Responsvel Tcnico Data: 26/04

1. necessrio um controle por login e senha de funcionrios no sistema? (X) Sim ( ) No

2. Quais os dados sobre o Funcionrio so necessrio? Nome, cargo, um login e uma senha.

3. Quais os dados sobre o Cliente sero necessrios armazenar? Nome, CPF, e endereo.

4. Quais os dados sobre uma anlise so necessrios para realizar um relatrio? necessrio: A leitura da amostra, a leitura do Padro, a massa, o volume, o fator do H2 , o fator do padro, a diluio, a massa em Mg (Magnsio), o fator de diluio, a concentrao, a normalidade, e o volume da Pipeta.

5. Qual a periodicidade voc acredita ser adequada para a gerao de relatrios? Um relatrio dirio, outro mensal, e outro anual.

6. Como voc julga seu conhecimento em relao interao com softwares? ( ) Ruim, no consigo aprender. (X) Razovel, mas me adapto. ( ) Bom, me adapto fcil.

7. Como voc acha mais eficiente a visualizao de relatrios? ( ) Impresso

83 (X) Arquivo Digital

8. O que o relatrio precisa informar? No relatrio, sero mostradas as quantidades de Nitrognio, Fsforo e Potssio de cada anlise. Para que fiquem organizadas, seria interessante marc-las por data, e algum outro identificador. E se possvel, uma lista de relatrios por funcionrio e cliente.

9. Disserte sobre algo que no foi perguntado e voc acredite ser importante para a construo do software. Para realizar o clculo dos teores (Nitrognio, Fsforo e Potssio) existem algumas tabelas de onde se retiram alguns valores que se fazem necessrios. Seguem abaixo:

AMOSTRA 2 A 4% 5 A 12% acima 15% URIA

NORMALIDADE 0,1 0,2 0,5 0,5 AMOSTRA 5 A 10% 11 A 30% acima 30%

VOL. PIPETA 10 ml 5 ml 5 ml

VALOR 50 100,00 250,00

AMOSTRA 8 A 18% CONC. PADRO 14 15 16 18 20 LEITURA 70 75 80 90 100 20 A 30% KCL 60%

VOL. PIPETA 10 ml 5 ml 5 ml

VALOR 1,25 2,50 5,00

84

APNDICE B ESTUDO DE VIABILIDADE

Diandra Kubo Software QuimiA Estudo de Viabilidade

Verso 1.2

85

Histrico da Reviso
Data <21/06/2010> <23/04/2011> Verso <1.0> <1.2> Descrio <Primeira verso do Software QuimiA> O Software QumiA destinado empresa ADM, para o auxlio na rea de clculo de teores, podendo ser utilizado em outra empresas do ramo. Autor Diandra Kubo

Diandra Kubo

Estudo de Viabilidade
INTRODUO Na empresa Archer Daniels Midland - ADM, situada na cidade de Paranagu, so produzidos fertilizantes minerais para uso em culturas variadas. Para esse feitio, importante que haja o controle de qualidade da matria-prima e do produto final, que so os fertilizantes. O controle de qualidade dividido em duas partes: Anlises qumicas e anlises fsicas. Dentro dos processos de anlises, os clculos e resultados so feitos e armazenados em planilhas eletrnicas, de modo rudimentar. nesse ponto que entra a necessidade de um software que ser um auxiliador.

FINALIDADE Nos dias de hoje, quando pretendemos fazer algo importante ou s vezes nem tanto essencial que faamos um planejamento antes de tudo. Santos Dumont estudou muito a aerodinmica, e Thomas Edison a eletricidade, antes de ambos criarem, respectivamente, o avio e a lmpada. O planejamento e o estudo de quais eram as necessidades e quais eram as possibilidades para que o problema fosse resolvido foram de suma importncia, e fizeram todo diferencial do que se ambos tivessem apenas comeado pela tentativa e erro. Hoje em dia, com a tecnologia, o desenvolvimento de softwares voltados para a informatizao de estabelecimentos ou para realizar tarefas simples do cotidiano vem se tornando cada vez mais comum, ao mesmo passo que mais utilizado. De tal maneira, um software tambm precisa ser detalhadamente projetado e analisado antes de sua implementao, justamente para torn-la melhor, eficiente, ou rpida; dependendo da requisio do cliente. Esse estudo de viabilidade, como o prprio nome j diz faz, a partir de vrias informaes sobre o futuro software, uma anlise de quais so as alternativas viveis ou no, para a resoluo do problema qual o software pretende auxiliar. O software QuimiA agilizar, tanto quanto dar mais segurana rotina de clculos das anlises qumicas da empresa, principalmente no clculo de teores, que atualmente feito apenas em planilhas eletrnicas.

87

DEFINIES, ACRNIMOS E ABREVIAES Clculo de Teores A partir das garantias do NPK, quando essas esto corretas, calculado a normalidade de cada teor (Nitrognio, Fsforo, Potssio). Granulometria Consiste na anlise do tamanho mdio ideal dos gros. Dureza Anlise da consistncia do gro. ndice de Normalidade A partir da porcentagem obtida pelo clculo de teores, chegado a um nmero que indica, a nvel de reconhecimento tcnico, qual a normalidade do produto. Garantias do NPK Ao produzir um produto, a empresa tem especificadas as quantidades de Potssio, Nitrognio e Fsforo que o produto dever ter. Essas quantidades pr-determinadas, so chamadas de Garantias do NPK. BUG -Termo utilizado para denominar um erro, na rea da informtica. JVM Java Virtual Machine, a Mquina Virtual da linguagem Java.

VISO GERAL Este estudo de viabilidade conter uma anlise do projeto em si, lhe informando todos os aspectos positivos e negativos do projeto e dizendo tambm se este vivel ou no. No captulo dois, o seu objetivo mostrado: auxiliar as anlises qumicas na obteno do resultado de normalidade do produto final e da matria prima, que controla a qualidade desses em questo. No captulo trs, o software tem seu escopo mostrado, ressaltando os aspectos que sero ou no cobertos, informando-nos passo a passo do que o projeto ir fazer e o que este deixar de fazer por motivos especficos, desde o recebimento da matria-prima at o certificado final de qualidade. No mesmo passo, no captulo quatro, temos a descrio da situao atual do problema-questo que o software visa agilizar. Explica o que ser acontece passo por passo atualmente, mostrando at mesmo seus respectivos problemas. J no captulo cinco, temos a apresentao das alternativas existentes para a resoluo desse problema, informando como cada uma detalhadamente, nesse caso, a linguagem C, e a linguagem Java.

88

No captulo seis, h a indicao dos desenvolvedores do estudo de viabilidades para a alternativa mais vivel, que neste caso foi a segunda, a linguagem Java. O capitulo se desdobra em subttulos, que nos mostram as suas vantagens e desvantagens em relao a este problema. Nesse caso, as vantagens superaram facilmente as desvantagens. A linguagem Java porttil, fcil de ser usada, mais eficiente, e melhor para o tipo de software que se pretende fazer. O nico risco apresentado, tem uma probabilidade muitssimo pequena de vir a ocorrer. Aps descrevermos todo esse processo, no captulo sete temos nossa concluso, em que o autor deste estudo de viabilidade informa ao seu cliente se este projeto ser ou no vivel de acordo com tudo o que foi levado em conta, que para este projeto, considerado vivel. Ao final, no captulo oito, esto nossas referencias bibliogrficas, de onde tiramos base para realizar nossos estudos. E no captulo nove, assinamos nossa responsabilidade.

89

OBJETIVO O Software QuimiA tem como objetivo auxiliar as anlises qumicas de uma empresa de fertilizantes. A partir da insero de dados das anlises qumicas anteriormente fornecidos pelos analistas,o software ir calcular o ndice de normalidade de cada teor (Nitrognio, Potssio, Fsforo), ou seja, far o clculo dos teores.

ESCOPO O projeto abrange inicialmente, somente a rea das anlises qumicas. O cliente ir fornecer os dados necessrios, como massa, leitura da amostra, fator de diluio e etc, que foram obtidos por meio de anlises anteriormente realizadas. A partir desses dados, sero calculados quais so os teores de

Nitrognio, Potssio e Fsforo. Com esses dados, calculado o ndice de normalidade de cada teor do produto final bem como da matria-prima. A cada resultado obtido ser mostrado um relatrio simples sobre a anlise que foi feita, que conter informaes como data, hora, resultado, os dados que foram inseridos, etc. Quando o cliente desejar, poder gerar um relatrio com as anlises do dia inteiro, que estaro salvas em um banco de dados, e se o cliente desejar, mandar imprimir. Caso o cliente tenha errado alguma anlise, ou seja, tenha entrado com dados equivocados, poder alterar determinada anlise. Tambm ser possvel excluir, se tiver feito uma anlise que j fora realizada, bem como adicionar uma que tenha ficado de fora. Uma mdia de anlises feitas durante o ms desejado poder ser invocada pelo cliente, assim como uma mdia de anlises feitas durante o ano, mostrando as estatsticas de cada uma.

90

No haver um relatrio geral, mostrando os resultados de cada anlise feita no ms/ano, pela extenso que o relatrio teria, no fazendo com que se tornasse algo prtico.

DIAGNSTICO ATUAL A situao atual na empresa, na parte do controle de qualidade, a seguinte: primeiro, h o recebimento da matria-prima e do produto final que se chegou a partir da mesmo, que nesse caso so os fertilizantes. Para se fazer o controle da qualidade de ambos, so necessrias duas etapas: as anlises fsicas e as anlises qumicas. Na parte de anlises fsicas, so feitas as anlises de Granulometria e de Dureza dos gros. Enquanto nas anlises qumicas, primeiro so feitas anlises que pretendem comprovar se as garantias do NPK esto corretas. Se estiverem dentro do esperado, com os valores feito o clculo dos teores Os clculos utilizados, so todos feitos lanando os dados em planilhas do Excel, onde aps a obteno dos resultados, so lanados para um boletim, que tambm uma planilha eletrnica, para que seja feito o laudo, e seqencialmente a impresso do mesmo, juntamente com o certificado da anlise. Os resultados, ento, ficam todos salvo separadamente em planilhas. Portanto, assim que se chega ao resultado da qualidade do produto. Aps tudo isso, os relatrios so salvos para posteriormente, serem gerados os relatrios separadamente, de forma rudimentar. ALTERNATIVAS EXISTENTES As propostas para a resoluo do problema, so:

ALTERNATIVA 1

91

A primeira alternativa para esse caso,seria continuar tudo da mesma forma que se est, pois as planilhas eletrnicas, apesar de tudo, so sim facilitadoras de alguns processos, como fazer o clculo, porm esta no uma propriedade exclusiva da mesma. ALTERNATIVA 2

A segunda alternativa seria elaborar um software que se encarregasse de cobrir todo o escopo do projeto descrito. Esse software seria implementado na linguagem de programao orientada a objetos, Java. Ele teria um acesso restrito a pessoas que tivessem um login e uma senha, que at faria a identificao de quem fez cada anlise.

ALTERNATIVA RECOMENDADA

A alternativa recomendada a alternativa nmero 2, programar o software em Java.

BENEFCIOS Ser muito melhor para o cliente que a sua rotina de clculos, bem como o armazenamento do resultados dos mesmos sejam feitos por meio de um software. Por planilhas no Excel, os clculos, suas constantes, e seus resultados podem facilmente serem alterados, propositalmente ou no. Se as planilhas so apagadas, perdem-se todos os dados, e as planilhas, pensando-se em um tempo maior, ficariam em grande quantidade, e alm de ocupar muito espao, no seria prticas no quesito organizao. Com o software, tudo ser feito de forma interligada, simples e com muito mais segurana em relao aos dados do cliente..

RECURSOS E CUSTOS

92

O software em questo no custar nada empresa para o qual est sendo desenvolvido, pelo menos inicialmente. Como est em fase inicial, pretendemos que o software seja testado no dia-a-dia, e se o seu bom funcionamento for confirmado, acreditamos que ele possa realmente ser comercializado para outras empresas tambm. Os recursos requeridos, so apenas a doao de algumas planilhas que so utilizadas atualmente na empresa, para que se tenha o conhecimento de quais so os valores fixos nos clculos, bem como os prprios. RISCOS Identificao do Risco Descrio do Risco BUG nas verses recentes da JVM. Probabilidade Impacto Severidade Ao de Preveno Antes de instalar o software, verificar a JVM do computador que ser utilizado. Oferecer cursos sobre o software aos funcionrios.

01

Baixa

Alto

Alta

02

No adaptao dos funcionrios ao software

Media

Medio

Media

CONCLUSES Portanto, vimos que um estudo de viabilidade de extrema importncia para iniciarmos o projeto no s do nosso software, mas tambm de outras coisas. Esse estudo de viabilidade mostrou que a melhor soluo para o problema sim implementar um software que ir poupar tempo, ser mais seguro, mais organizado, e com menos riscos. O software ir fazer o clculo dos teores, indicando o ndice de normalidade, e com os resultados gerar relatrios dirios e mensais. A partir desse ponto, podero ser visualizados as estatsticas anuais da empresa, o que pode ser til quando se

93

quiser analisar qual tipo de matria-prima no tem correspondido s garantias de NPK, bem como os prprios fertilizantes. Em suma, o projeto do software QuimiA ser implantado no lugar de planilhas eletrnicas se mostrou vivel, levando em considerao seus poucos risco e muitos benefcios. REFERNCIAS BIBLIOGRFICAS BELEM (Par). UNIVERSIDADE FEDERAL DO PAR. Centro Scio Econmico; Departamento de Contabilidade. montagem de In: Estudo de Viabilidade v. 1. de Pequenos em:

Empreendimentos:

Um

Bar,1999.

Disponvel

<http://paraiso.etfto.gov.br/docente/admin/upload/docs_upload/material_5987d85119 .pdf> . Acesso em : 13 mai.2010.

DEITEL, Harvey M. Java: Como Programar 6 edio.

94

RESPONSABILIDADES

_______________________________________________ Diandra Akemi Alves Kubo

Data:____/____/________