protÓtipo de um sistema de informaÇÕes...
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
(Bacharelado)
PROTÓTIPO DE UM SISTEMA DE INFORMAÇÕES EXECUTIVAS PARA REPRESENTANTES COMERCIAIS DO
RAMO TÊXTIL
TRABALHO DE CONCLUSÃO DE CURSO SUBMETIDO À UNIVERSIDADE REGIONAL DE BLUMENAU PARA A OBTENÇÃO DOS CRÉDITOS NA
DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE CIÊNCIAS DA COMPUTAÇÃO — BACHARELADO
FÁBIO DEMARCHI INOCENTI
BLUMENAU, JUNHO/2000
2000/1-19
PROTÓTIPO DE UM SISTEMA DE INFORMAÇÕES EXECUTIVAS PARA REPRESENTANTES COMERCIAIS DO
RAMO TÊXTIL
FÁBIO DEMARCHI INOCENTI
ESTE TRABALHO DE CONCLUSÃO DE CURSO, FOI JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS NA DISCIPLINA DE TRABALHO DE
CONCLUSÃO DE CURSO OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE:
BACHAREL EM CIÊNCIAS DA COMPUTAÇÃO
Prof. Ricardo Alencar de Azambuja — Orientador na FURB
Prof. José Roque Voltolini da Silva — Coordenador do TCC
BANCA EXAMINADORA
Prof. Ricardo Alencar de Azambuja Prof. Oscar Dalfovo Prof. Wilson Pedro Carli
AGRADECIMENTOS
Gostaria de agradecer em primeiro lugar a Deus, por tornar possível a realização deste.
Agradecer aos meus pais, Sr. Osmar e Sra. Lúcia Inocenti, que sempre pacientemente estiveram a minha disposição na tão árdua tarefa de educar, e tão ansiosamente quanto eu, esperaram por este momento.
Agradecer também à minha esposa Margareth Volles Demarchi Inocenti, pela paciência e incentivo sempre me disponibilizados, bem como minha irmã Lucimar Inocenti, pela força que nunca faltou.
É necessário também, agradecer as pessoas que sempre me apoiaram no campo acadêmico, sejam os amigos pelos momentos de descontração, em especial Moacir Ezequiel Lamego, ou os professores que enaltecem o nosso conhecimento, notavelmente os Srs. Ricardo Alencar de Azambuja, Oscar Dalfovo e Sérgio Stringari.
SUMÁRIO LISTA DE FIGURAS ..............................................................................................................vii RESUMO ..................................................................................................................................ix ABSTRACT ...............................................................................................................................x 1 INTRODUÇÃO.....................................................................................................................2 1.1 LEVANTAMENTO DE INFORMAÇÕES.........................................................................3 1.2 METAS DO SETOR ............................................................................................................5 1.3 MOTIVAÇÃO.....................................................................................................................5 1.4 OBJETIVOS........................................................................................................................6 1.5 ORGANIZAÇÃO DO TEXTO...........................................................................................6 2 CONCEITOS BÁSICOS .......................................................................................................7 2.1 SISTEMAS..........................................................................................................................7 2.2 DADOS E INFORMAÇÕES ..............................................................................................8 2.3 SISTEMAS DE INFORMAÇÃO.........................................................................................9 3 SISTEMAS DE INFORMAÇÕES EXECUTIVAS - EIS...................................................10 3.1 HISTÓRICO.......................................................................................................................10 3.2 CONCEITOS E CARACTERÍSTICAS............................................................................11 3.3 VANTAGENS...................................................................................................................13 3.4 DESVANTAGENS ...........................................................................................................14 3.5 IMPLANTAÇÃO DE UM EIS .........................................................................................14 3.6 METODOLOGIA PARA IMPLANTAÇÃO DE UM EIS ...............................................15 3.6.1 FASE I - PLANEJAMENTO..........................................................................................15 3.6.1.1 Estágio I - Organização do Projeto...............................................................................15 3.6.1.2 Estágio II - Definição de Indicadores ...........................................................................16 3.6.1.3 Estágio III - Análise de Indicadores .............................................................................16 3.6.1.4 Estágio IV - Consolidação de Indicadores....................................................................16 3.6.1.5 Estágio V - Desenvolvimento de Protótipos.................................................................17 4 UML - UNIFIED MODELING LANGUAGE......................................................................18 4.1 HISTÓRICO......................................................................................................................18 4.2 CONCEITOS.....................................................................................................................20 4.3 CARACTERÍSTICAS.......................................................................................................21 4.4 DIAGRAMAS...................................................................................................................23 4.5 DIAGRAMA DE CLASSES.............................................................................................23 4.5.1 CLASSE..........................................................................................................................26 4.5.2 ATRIBUTOS ..................................................................................................................27 4.5.3 OPERAÇÕES .................................................................................................................27 4.6 DIAGRAMA DE CASOS DE USO .................................................................................27 4.6.1 ATOR..............................................................................................................................29 4.6.2 CASO DE USO...............................................................................................................30 4.6.3 INTERAÇÃO EM CASO DE USO................................................................................31 5 ESPECIFICAÇÃO DO PROTÓTIPO ................................................................................34 5.1 ESCOPO DO PROTÓTIPO..............................................................................................34 5.2 IMPLEMENTAÇÃO ........................................................................................................34 5.2.1 NECESSIDADES DO USUÁRIO..................................................................................35 5.2.2 LEVANTAMENTO DE REQUISITOS.........................................................................35 5.2.3 DESENVOLVIMENTO DO PROTÓTIPO....................................................................38
5.3 FUNCIONAMENTO DO PROTÓTIPO ..........................................................................39 5.3.1 CLIENTES......................................................................................................................40 5.3.2 FORNECEDORES .........................................................................................................41 5.3.3 PEDIDOS........................................................................................................................42 5.3.4 RELATÓRIOS................................................................................................................45 5.3.4.1 Venda por Cliente .........................................................................................................45 5.3.4.2 Venda por Fornecedor ..................................................................................................46 5.3.4.3 Comissões .....................................................................................................................49 5.3.4.4 Clientes .........................................................................................................................51 6 CONCLUSÕES...................................................................................................................53 6.1 SUGESTÕES ...................................................................................................................54 ANEXOS..................................................................................................................................55 REFERÊNCIAS BIBLIOGRÁFICAS .....................................................................................60
LISTA DE FIGURAS FIGURA 1 – INTEGRAÇÃO DO E.I.S. COM SISTEMAS EXISTENTES NA EMPRESA 10 FIGURA 2 – RELACIONAMENTO DE UM E.I.S. COM OUTROS SISTEMAS.............. ..13 FIGURA 3 – RESUMO DO HISTÓRICO DA UML..............................................................20 FIGURA 4 – EXEMPLO RELACIONAMENTO GENERALIZAÇÃO/ESPECIFICAÇÃO 24 FIGURA 5 – EXEMPLO DE RELACIONAMENTO DE AGREGAÇÃO ............................24 FIGURA 6 – REPRESENTAÇÃO DE UMA ASSOCIAÇÃO ...............................................25 FIGURA 7 – REPRESENTAÇÃO DE UMA DEPENDÊNCIA.............................................25 FIGURA 8 – EXEMPLO DE CLASSE ...................................................................................26 FIGURA 9 – EXEMPLO DE UM DIAGRAMA DE CASO DE USO ...................................28 FIGURA 10 – EX. DIAGRAMA DE CASO DE USO COM 3 TIPOS DE INTERAÇÕES ..32
FIGURA 11 – METODOLOGIA DA PROTOTIPAÇÃO ......................................................34 FIGURA 12 – DIAGRAMA DE CLASSES............................................................................36 FIGURA 13 – DIAGRAMA DE CASOS DE USO.................................................................36 FIGURA 14 – DIAGRAMA DE CASOS DE USO.................................................................37 FIGURA 15 – DIAGRAMA DE EVENTOS/INTERAÇÕES (EMISSÃO DE PEDIDOS) ...38 FIGURA 16 – TELA PRINCIPAL DO PROTÓTIPO.............................................................39 FIGURA 17 – TELA DE CADASTRO DE CLIENTES.........................................................40 FIGURA 18 – TELA DE CADASTRO DE FORNECEDORES ............................................41 FIGURA 19 – TELA DE EMISSÃO DE PEDIDOS...............................................................43 FIGURA 20 – EXEMPLO DE UM PEDIDO VISUALIZADO NA TELA............................44 FIGURA 21 – VENDAS POR CLIENTE................................................................................45 FIGURA 22 – VISUALIZAÇÃO DO RELATÓRIO VENDAS POR CLIENTES ................46 FIGURA 23 – VENDAS POR FORNECEDOR......................................................................47 FIGURA 24 - VISUALIZAÇÃO DO RELATÓRIO VENDAS POR FORNECEDOR.........47 FIGURA 25 – GRÁFICO DE VENDAS POR FORNECEDOR.............................................48 FIGURA 26 – TELA DO RELATÓRIO DE COMISSÕES....................................................49 FIGURA 27 – VISUALIZAÇÃO DO RELATÓRIO DE COMISSÕES ................................50 FIGURA 28 – GRÁFICO DE COMISSÕES POR FORNECEDOR ......................................51 FIGURA 29 – TELA DO RELATÓRIO DE CLIENTES .......................................................51 FIGURA 30 – VISUALIZAÇÃO DO RELATÓRIO DE CLIENTES....................................52
RESUMO
Para atender a uma classe específica, a dos representantes comerciais, do ramo têxtil, este trabalho descreve um estudo sobre o Sistema de Informações Executivas e alguns conceitos da UML (Unified Modeling Language). O estudo é complementado com a descrição de um protótipo voltado às necessidades desta classe de trabalhadores.
ABSTRACT
To assist to a specific class, the one of the commercial representatives, of the textile branch, this work describes a study on Executive Information Systems and some characteristics about UML - Unified Modeling Language. The study is complemented with the description of a prototype returned to the needs of this class of workers.
2
1 INTRODUÇÃO
As indústrias têxteis estão inseridas em um ramo de altíssima competitividade, onde é preciso estar inovando sempre, atualizando-se em busca da antecipação das tendências do mercado. A principal atividade econômica, no Vale do Itajaí, é o setor têxtil. Existe na região, um número considerável de empresários deste setor. Empresários, estes, dispostos a atender bem aos seus clientes, e para tanto, dispostos a adquirir matéria-prima da melhor qualidade pelo melhor preço. Porém, a matéria-prima, da qual necessitam os empresários, não é totalmente produzida no Vale do Itajaí, caracterizando-se a forma da representação comercial. Em geral, um profissional liberal, que presta serviços à empresas fornecedoras de matéria-prima. Estes profissionais precisam estar, em tempo integral, inseridos no mercado.
Tornou-se de extrema necessidade para as organizações a missão de administrar as informações, porque existe uma crescente demanda e sofisticação na tecnologia da informação de software. Esse recurso será de vital importância para a sobrevivência das empresas [DAL1998].
Segundo [SAL1994], os Sistemas de Informação, em especial os Sistemas de Informações Executivas (E.I.S.), surgiram como uma forma de manter o executivo preparado para as mudanças, com visão integrada de todas as áreas da empresa, isto sem gastar muito de seu tempo e também sem requerer do mesmo um conhecimento aprofundado de cada área.
De acordo com o mesmo [SAL1994], a área comercial de uma organização, particularmente a administração de vendas, pode ser vista como o Sistema Nervoso Central da mesma; apesar de todas as áreas serem igualmente importantes praticamente todas tratam de processos iniciados pela área de negócios da empresa. Sendo este setor o núcleo da organização e diretamente influenciada pelo meio externo, torna-se claro que é o mais sujeito a modificações. Sendo assim, o administrador desta área necessita de um sistema rápido, seguro e eficaz de informações que o auxilie no gerenciamento da mesma, tendo uma visão geral do andamento do mercado e do desempenho da empresa no mesmo.
Para [OLI1992] o Sistema de Informações Executivas, é o processo de transformação de dados em informações que são utilizadas na estrutura decisória da empresa, bem como proporcionam a sustentação administrativa para otimizar os resultados esperados.
Basicamente, segundo [DAL1998], para ser considerada uma ferramenta de E.I.S. esta deve possuir agilidade na obtenção de informação, facilidade na utilização por meio de ícones e botões via clique de mouse, flexibilidade de navegação do nível sintético até o analítico de forma simples e clara, qualidade da informação e segurança no acesso.
Diretamente derivada dos conceitos de programação e do projeto orientado a objeto, a análise e o desenho orientados a objeto são certamente a mais nova das abordagens de desenvolvimento de sistemas. A tecnologia de objetos apresenta componentes chaves que fundamentam a mudança de enfoque no processo de modelagem e desenvolvimento de aplicações, trazendo benefícios intrínsecos à filosofia. [FUR1998], também cita Rumbaugh que define orientação a objetos como “uma nova maneira de pensar os problemas utilizando modelos organizados a partir de conceitos do mundo real. O componente fundamental é o objeto que combina estrutura e comportamento em uma única entidade”.
3
O sistema de informação para executivos (E.I.S.) são voltados para os administradores com pouco, ou quase nenhum contato com Sistemas de Informação automatizados. As características deste tipo de sistema consistem em combinar dados internos e externos; na utilização de menus gráficos; no acesso a banco de dados internos e externos; e os dados são mostrados nos relatórios impressos de forma comprimida ([DAL1998]).
1.1 LEVANTAMENTO DE INFORMAÇÕES
Segundo [ACI2000], a qualidade de vida no Vale do Itajaí é uma das melhores do Brasil. Recentemente a ONU publicou o ranking das melhores cidades brasileiras, segundo os respectivos indicadores sociais. E das 50 melhores posicionadas, sete eram do médio Vale do Itajaí, que é constituído de 14 municípios.
Nossa região possui uma “marca forte” (certificado de origem) reconhecida nacional e internacionalmente, exatamente porque no Vale temos uma mão-de-obra qualificada e facilmente qualificável, um povo ordeiro e trabalhador (com predominância da cultura alemã e italiana), ótima sinergia para as atividades industriais (têxtil, confecções, metal-mecânica, plásticos, gráfico, madeireira, etc.). Além disso, um pólo de excelente logística para alcançar os principais mercados do Mercosul (pela via rodoviária, aérea e marítima)([ACI2000]).
De acordo com dados de [ACI2000], Blumenau conta hoje, com uma população estimada de 290.000 habitantes, e tem como atividade predominante no município o ramo têxtil. Além de possuir mão-de-obra treinada para a indústria têxtil, a cidade de Blumenau ocupou recentemente o 9º (nono) lugar no Ranking das 10 melhores cidades para se fazer negócios no Brasil, conforme pesquisa realizada pela revista Exame, edição 713, em parceria com a Simisen Associados, empresa de consultoria de São Paulo.
A tabela abaixo, adaptada de [MAR1999], nos mostra os investimentos planejados para a modernização do setor têxtil no Brasil até o ano 2002:
Tabela 1 – Investimentos planejados para o setor têxtil
Uma outra prova de que o setor continua acreditando em seu crescimento no Brasil pode ser dada pela análise dos planos de investimentos nas unidades fabris, estimados pelas empresas em cerca de US$ 1,2 bilhão anuais para os próximos cinco anos ([MAR1999]).
Sub-Setor Invest./Ano Período Invest./Total
US$ milhões Anos US$ milhões
Fibras químicas 280 3 840 Fiação fibra curta 158 5 790 Tecelagem 110 5 550 Malharia 123 3 369 Beneficiamento 307 5 1.535 Confecção 400 5 2.000 Total 6.084
4
Uma classe deste setor, a dos representantes comerciais, ainda são carentes de sistemas computadorizados que venham a contemplar suas necessidades diárias. Daí surgiu a idéia, em conjunto com o orientador deste trabalho, o professor Ricardo Alencar de Azambuja, e o professor Oscar Dalfovo, de desenvolver um protótipo que tivesse por objetivo principal, auxiliar nas tarefas básicas de um representante comercial do setor têxtil.
1.2 METAS DO SETOR
As metas do setor têxtil a serem atingidas num prazo de cinco anos são, no mínimo, ambiciosas. Porém, o presidente da Associação Brasileira da Indústria Têxtil (Abit), o Sr. Paulo Skaf, diz que se forem atendidas as políticas prioritárias elaboradas pelos têxteis, as metas são perfeitamente possíveis de serem atingidas. Essas metas estão prevendo a geração de mais de 400 mil empregos e um aumento nas exportações a US$ 4,3 bilhões, 1% do mercado mundial, até o ano de 2005. Para atingí-las, seriam necessários investimentos na ordem de US$ 12,3 bilhões em oito anos, aumento em mais de 600 mil hectares em área plantada de algodão, aumento de toda a cadeia produtiva têxtil em torno de 70% e aumento da produtividade em torno de 20% ([SKA2000]).
De acordo com o mesmo [SKA2000], nos últimos sete anos foram investidos cerca de US$ 7 bilhões no setor têxtil. Já foi feita a lição de casa, o momento é de mostrar competitividade. Hoje, há 1,5 milhão de empregos somente na cadeia produtiva, sem contar os cotonicultores e mais de 20 mil empresas têxteis abertas. O Brasil este ano deve exportar US$ 1,4 bilhão, cerca de 0,4% do total mundial, ou seja, é possível chegar a 1% de toda a movimentação de exportação do setor.
1.3 MOTIVAÇÃO
Como os representantes comerciais encaixam-se neste perfil de administrador, um sistema de informações executivas torna-se apropriado à classe. Um representante comercial, de um modo geral, é um profissional liberal que atende a uma gama de clientes que facilmente ultrapassa à contagem centenária. Sendo assim, é praticamente impensável que o representante possa armazenar os dados de todos os seus clientes em sua própria memória.
O representante comercial necessita de informações para a tomada de decisão, que vão além dos dados de cada empresa (endereço, telefone, CGC e Inscrição Estadual quando da emissão de um pedido, e aí entram também os dados dos seus fornecedores) até os produtos específicos para atender às necessidades de cada cliente, bem como informações úteis à sua visita, tais como: data da última compra, valor da última compra, forma de pagamento de cada cliente, etc.
1.4 OBJETIVOS
Os principais objetivos deste trabalho são:
5
a) realizar um estudo da filosofia de Sistemas de Informações; b) realizar um estudo das técnicas de modelagem da UML; c) a especificação de um protótipo de acordo com as normas da UML; d) a implementação de um protótipo de um S.I.E., que auxilie nas tarefas
administrativas de representantes comerciais do ramo têxtil.
1.5 ORGANIZAÇÃO DO TEXTO
A seguir será feita uma descrição resumida de cada capítulo do trabalho.
O primeiro capítulo apresenta o assunto deste trabalho como um todo. Trazendo a motivação para a realização do mesmo, bem como os objetivos e a forma através da qual será organizado.
No segundo capítulo, serão expostos os conceitos básicos dos sistemas de informações.
O terceiro capítulo trata especificamente dos Sistemas de Informações Executivas – E.I.S., apresentando suas características, vantagens e desvantagens.
No quarto capítulo, será apresentada a proposta UML, descrevendo o histórico de seu surgimento, a sua arquitetura e a notação relativa aos diagramas disponibilizados para a fase de análise da modelagem de um sistema orientado à objetos.
No quinto capítulo, serão feitas as considerações relativas ao protótipo. Serão descritos a definição do protótipo, sua especificação e o seu funcionamento.
No sexto capítulo, serão apresentadas as principais conclusões do trabalho.
6
2 CONCEITOS BÁSICOS
Para se definir Sistemas de Informação, é preciso ter em mente algumas definições ou conhecimentos sobre o computador, hardware, software e telecomunicação. Existem diversas definições sobre sistemas de informação. Algumas definições se baseiam no modelo comportamental, outras no modelo técnico [DAL1998].
Modelo Comportamental – soluções comportamentais (utilização do sistema, implementação e desenho):
a) psicologia – Concentra-se nas reações dos indivíduos aos sistemas de informação e modelos cognitivos de racionalidade humana;
b) sociologia – Impactos sobre organizações, grupos, indivíduos e sociedade; c) ciência política – Determina impactos políticos e usos da informação.
Modelo Técnico – soluções técnicas ou estruturais: a) ciência da computação – Teoria da computação, métodos de computação e
métodos de armazenamento e acesso à dados; b) pesquisa operacional – Concentra-se em técnicas matemáticas para a otimização de
parâmetros de desempenhos selecionados nas organizações; c) ciência administrativa – Ênfase no desenvolvimento de modelos de tomada de
decisão e práticas administrativas.
2.1 SISTEMAS
Segundo [OLI1992], sistema pode ser definido como sendo: “um conjunto de partes interagentes e interdependentes que, conjuntamente, formam um todo unitário com determinado objetivo e efetuam determinada função”. Um sistema é um conjunto de elementos ou componentes que interagem para se atingir objetivos. Os próprios elementos e as relações entre eles determinam como o sistema trabalha. Os sistemas têm entradas, mecanismos de processamento, saídas e feedback [STA1998].
Os componentes de um sistema são mais bem explicados a seguir, conforme [LIM1999]:
a) objetivos: razão principal da existência do sistema, ou seja, é a razão para qual o sistema foi concebido;
b) entradas: tudo o que o processador do sistema recebe para processar, armazenar e gerar saídas;
c) processo de transformação: componentes do sistema que transformam as entradas em saídas, podendo efetuar várias operações como juntar, calcular, transformar, armazenar, selecionar, etc. Este processador é a maneira pela qual os elementos componentes interagem no sentido de produzir as saídas desejadas;
d) saídas: correspondem aos resultados do processo de transformação, é o produto final resultante do processamento das entradas;
e) controle e avaliação: componente que verifica periódica ou continuamente, se as saídas do sistema estão de acordo com os padrões estabelecidos, efetuando as correções necessárias para que o sistema atinja seus objetivos;
f) retroalimentação ou feedback: processo de comunicação que reage a cada entrada de informação incorporando o resultado da ação resposta desencadeada por meio
7
de nova informação, a qual afetará seu comportamento subsequente e assim sucessivamente. Seu objetivo é reduzir as discrepâncias ao mínimo.
2.2 DADOS E INFORMAÇÕES
Um dado deve ser diferenciado de uma informação, uma vez que um dado mantém a sua forma bruta, ou seja, analisando-se um dado isoladamente, não nos fará compreender uma determinada situação. Sendo que uma informação pode ser este mesmo dado, todavia, lapidado pelo executivo, observado dentro de um contexto, fato que o propicia tomar a decisão correta diante de qualquer situação. Sendo assim, informação é o dado, mas com a sua forma e conteúdo adequados à determinadas situações.
De acordo com [OLI1992], informação “é o dado trabalhado que permite ao executivo tomar decisões” e dado “é qualquer elemento identificado em sua forma bruta que por si só não conduz a uma compreensão de determinado fato ou situação”.
[STA1998] também nos fornece uma definição para dados e informações, um tanto quanto mais abrangente, onde coloca que, dados são os fatos em sua forma primária e informação é um conjunto de fatos organizados de tal forma que adquirem valor adicional além do valor do fato em si.
2.3 SISTEMAS DE INFORMAÇÃO
A tecnologia da informação é muitas vezes orientada por modismos. Há alguns anos, surgiu o fenômeno do “downsize – migração de sistemas dos grandes computadores para os médios e pequenos computadores” e dos sistemas abertos. Muitas empresas mergulharam de cabeça, sem uma análise crítica para saber se essa solução era realmente a mais adequada para os problemas que vinham enfrentando referente à informática. Hoje, o fenômeno da moda chama-se Sistemas de Informação. Eles podem ser realmente a solução para muitas empresas, mas, com certeza, outras estarão investindo muito dinheiro para pouco retorno. Investir em um Sistema de Informação significa, antes de tudo, saber exatamente do que se necessita e onde se quer chegar com essa solução. As empresas que têm claramente estas questões e se preocupam em implementar este sistema, vão ser bem sucedidas [TAU1998].
De acordo com [PRA1994], Sistemas de Informação são formados pela combinação estruturada de vários elementos, organizados da melhor maneira possível, visando atingir os objetivos da organização. São integrantes dos sistemas de informação: a informação (dados formatados, textos livres, imagens e sons), os recursos humanos (pessoas que coletam, armazenam, recuperam, processam, disseminam e utilizam as informações), as tecnologias de informação (o hardware e o software utilizados no suporte aos Sistemas de Informação) e as práticas de trabalho (métodos utilizados pelas pessoas no desempenho de suas atividades).
Segundo [LAU1997], os Sistemas de Informação são divididos em seis grandes tipos, dentre os quais se encontra um dos objetos do nosso estudo (capítulo 3) que é o Sistema de Informação para Executivos.
8
3 SISTEMA DE INFORMAÇÃO EXECUTIVA – EIS
3.1 HISTÓRICO
O termo Executive Information System (Sistema de Informação Executiva), surgiu no final da década de 1970, a partir dos trabalhos desenvolvidos no Massachusetts Institute of Tecnology (MIT) por pesquisadores como Rochart e Treacy. O conceito se espalhou por várias empresas de grande porte e no final da década de 1980, um terço das grandes empresas dos Estados Unidos da América (EUA) possuíam ou encontravam-se em vias de implementar algum EIS [FUR1994].
Para [DAL1998], um dos maiores questionários feitos sobre o processo de E.I.S. são quanto à melhor maneira de integrá-lo aos sistemas já existentes nas empresas. Em 1990, uma visão predominou o início da década, foram o E.S.S. (Executive Support Systems – Sistemas de Suporte para Executivos). Nos anos 80, o E.I.S. era visto como um sistema situado no topo de uma pirâmide tradicionalmente usada para representar a hierarquia de sistemas. Essa pirâmide tinha no seu nível intermediário os D.S.S. (Decision Support Systems – Sistemas de Suporte de Decisão) e, em sua base, os S.O. (Sistemas Operacionais), conforme demonstrado na figura 1.
Figura 1. Integração do E.I.S. com sistemas existentes na empresa.
E.I.S.
D.S.S.
S.O.
Fonte: Adaptado de [DAL1998], p.19
3.2 CONCEITOS E CARACTERÍSTICAS
Furlan [FUR1994] define Executive Information Systems (EIS) como sendo: “Um mecanismo computadorizado que fornece aos executivos as informações necessárias para gerenciar o negócio. Os E.I.S. são sistemas computacionais destinados a satisfazer necessidades de informação dos executivos, visando eliminar a necessidade de intermediários entre estes e a tecnologia”. Os executivos consideram que os dados contidos nos arquivos de computadores são uma excelente fonte de informações para a tomada de decisões. Não é uma
9
questão de modernidade comandar uma empresa por meio de computadores em vez de papéis, mas principalmente de flexibilidade e rapidez. Em função da complexidade do mercado, as empresas estão sendo obrigadas a agilizar seu processo de decisão. Um E.I.S. (Executive Information Systems – Sistemas de Informação para Executivos) permite ao executivo acompanhar diariamente os resultados, tabulando dados de todas as áreas funcionais da empresa, para depois exibí-los de forma gráfica e simplificada. O E.I.S. envolve poucas pessoas no processo, o que minimiza custos administrativos, diminuindo a ocorrência de erros.
Segundo [DAL1998], os sistemas de informações executivas são voltados para os administradores com pouco, ou quase nenhum contato com sistemas de informações automatizados. As características deste tipo de sistema consistem em combinar dados internos e externos; na utilização de menus gráficos; no acesso a banco de dados internos e externos; e os dados são mostrados nos relatórios de forma comprimida.
De acordo com [FUR1994], o E.I.S. é um meio prático para os executivos acessarem as informações disponíveis em seus sistemas computadorizados, de forma simples e voltados às suas necessidades. O E.I.S. oferece um meio prático de acesso às informações estratégicas com uma interface/máquina amigável e disponível com um simples apertar de botões do mouse. As informações necessitadas pelos executivos são apresentadas pelos E.I.S., com o conteúdo ajustado ao seu estilo de trabalho. O E.I.S. é uma ferramenta de consulta às bases de dados para a apresentação de informações, com característica amigável e simples, atendendo às necessidades dos executivos.
A seguir, podemos ver algumas características principais dos sistemas de informações executivas, segundo [FUR1994]:
a) destinam-se a atender às necessidades informacionais dos executivos; b) são usados principalmente para acompanhamento e controle; c) possuem recursos gráficos de alta qualidade para que as informações possam ser
apresentadas graficamente de várias formas e as variais e exceções possam ser realçadas e apontadas automaticamente;
d) destinam-se a proporcionar informações de forma rápida para decisões que são tomadas sob pressão;
e) são fáceis de usar, para que os executivos não tenham necessidade de receber treinamento específico em informática;
f) são desenvolvidos de modo a se enquadrar na cultura da empresa e no estilo de tomada de decisão de cada indivíduo;
g) filtram, resumem e acompanham dados críticos; h) fazem uso intensivo de dados do macroambiente empresarial (concorrentes,
clientes, indústria, mercados, governos, entre outros).
Segundo Kormann [KOR1993], nos E.I.S., a informação flui para vários sentidos. A informação origina-se dos diversos sistemas da empresa, de onde os dados são retirados, filtrados e analisados, terminando este processo na tomada de decisão. Porém após a tomada
10
de decisão, em um modo integrado, o sistema deve fornecer aos outros sistemas o resultado que esta decisão trará sobre a empresa, como podemos ver na figura 2.
Figura 2: Relacionamento de um E.I.S. com outros sistemas
Fonte: Adaptado de [KOR1993]
3.3 VANTAGENS
Os Executive Information Systems (E.I.S.) são de grande importância para o executivo e apresentam algumas vantagens, conforme [LIM1999]:
a) utilizam a tecnologia computacional mais recente para melhorar a produtividade da alta gerência;
b) agem como um filtro para os executivos, fazendo com que as informações sejam resumidas da maneira definida pelos usuários;
c) correspondem às preferências dos executivos; d) fornecem suporte à resolução de problemas gerenciais. No entanto, dão suporte
também à analise de oportunidade, ou pode simplesmente colocar um executivo numa melhor posição, de forma a entender as operações de sua empresa.
Além disso, um sistema de informações executivas (E.I.S.) pode ser combinado a outros sistemas de informação. Neste caso, a entrada de informações é transferida automaticamente para alguns sistemas de geração de modelos e o executivo realiza as mesmas análises com esses dados. Uma combinação deste tipo é importante, pois a cada coleta e
E.I.S.
Sistema de Controle de Estoques
Sistema Financeiro
Sistema de Compras
Outros Sistemas de Informação
11
análise de informações sobre o mercado, novas tecnologias, concorrentes e legislação é essencial [LIM1999].
3.4 DESVANTAGENS
Os Executive Information Systems (E.I.S.) apesar de serem uma grande vantagem para o executivo no auxílio à tomada de decisões estratégicas, para a empresa pode acabar sendo desvantagem pois as informações podem se tornar centralizadas nos executivos que tomam tais decisões.
Alvin Tofler colocou que a terceira onda é a da informação, ou seja, quem tiver a informação será mais competitivo. Isto pode acarretar nas organizações uma busca exacerbada por informação, ou seja, um executivo tentando absorver mais informações que o outro a fim de se destacar e/ou ser mais competitivo no mercado. [LIM1999].
De acordo com [MEL1990], na construção de Sistemas de Informações, existe um problema em termos de análise, pois, a cada decisão, a cada execução de um processo, novos dados são gerados, necessitando de armazenamento de forma estruturada, a fim de possibilitar posteriores recuperações de informações. Geralmente há um grande crescimento do banco de dados tornando a função de administrador de dados complexa e onerosa.
3.5 IMPLANTAÇÃO DE UM EIS
De acordo com [MAC1996] existem alguns passos que devem ser seguidos para a implantação do EIS:
a) projeto prático e realista: A idéia é não esperar que todas as condições ideais estejam prontas para só então iniciar a implantação de um sistema de EIS. Tire da cabeça a idéia do projeto “definido”. A própria dinâmica dos negócios não autoriza essa visão;
b) enfoque de cima para baixo: Um projeto de apoio à decisão deve ser implantado do topo para a base, a fim de garantir que seja voltado para necessidades gerenciais. Sua origem “natural” é a alta administração, que tem em mente os objetivos estratégicos da empresa;
c) flexibilidade e criatividade: Um sistema de EIS reflete o nível de criatividade e ousadia dos executivos que o traçam. É preciso adaptar recursos, fugindo à idéia das “soluções ideais”;
d) Usar técnicas de prototipação: A modelagem da base de dados para o projeto deve ser feita com a ajuda de ferramentas CASE. Isso garante mais consistência e facilita a manutenção e a ampliação do sistema; e
e) Desenvolver para os clientes: O sistema de apoio à decisão tem de ser ágil, amigável e voltado para os executivos, não para os técnicos. O importante nele é dar acesso fácil a informação.
12
3.6 METODOLOGIA PARA IMPLANTAÇÃO DE UM EIS
Furlan [FUR1994] propõe uma metodologia para elaboração do EIS que é composta por três fases, sendo que a primeira fase consiste no planejamento do EIS em si, na segunda fase é feito todo o projeto do sistema e é somente na última fase que o sistema será implementado.
Todavia, para o propósito de prototipação deste trabalho, a utilização apenas da fase I, descrita a seguir, torna-se suficiente.
3.6.1 FASE I – PLANEJAMENTO
Esta fase tem por finalidade definir conceitualmente o sistema EIS, identificando as necessidades de informação e o estilo decisório do executivo. Define também a estrutura básica do sistema e do protótipo preliminar de telas.
A fase de planejamento é composta por cinco estágios, sendo que no primeiro deles é feita a organização do projeto; o segundo estágio consiste na definição dos indicadores; o terceiro a análise de indicadores; o quarto estágio onde é feito a consolidação dos indicadores e finalmente, no quinto e último ocorre o desenvolvimento de protótipos.
3.6.1.1 ESTÁGIO I – ORGANIZAÇÃO DO PROJETO
É neste estágio que a equipe de trabalho é treinada nas técnicas de levantamento de dados e análise dos fatores críticos de sucesso. Onde são identificadas quais informações os executivos já recebem, por meio de questionário específico (Executive Information Survey).
As tarefas deste estágio são estabelecer a equipe de trabalho; conduzir reunião de abertura de projeto; anunciar o projeto à empresa; iniciar o Executive Information Survey; finalizar o plano de trabalho; e levantar o portfólio de sistemas e bases de dados.
3.6.1.2 ESTÁGIO II – DEFINIÇÃO DE INDICADORES
É neste estágio que cada executivo é entrevistado individualmente para que se possam identificar seus objetivos, fatores críticos de sucesso e necessidades de informação e, em seguida, efetuar a documentação para submeter os resultados à revisão. Deve-se antes das entrevistar conduzir uma sessão de planejamento a fim de rever os precedentes e, assim, traçar uma linha mesta de ação.
As tarefas deste estágio são: conduzir o planejamento pré-entrevista; conduzir entrevistas dos executivos; revisar e documentar entrevistas; obter aprovação dos executivos.
3.6.1.3 ESTÁGIO III – ANÁLISE DE INDICADORES
O objetivo deste estágio é normalizar as informações levantadas durante as entrevistas individuais dos executivos a fim de obter uma lista consolidada de objetivos, fatores críticos de sucesso, problemas e necessidades de informação. Esta lista é transformada numa matriz
13
de inter-relacionamento entre os indicadores de desempenho e os respectivos objetos de interesse dos executivos. Em seguida, são atribuídos pesos de importância e é elaborado um ranking de necessidades.
As atividades deste estágio são: consolidar objetivos, fatores críticos de sucesso e necessidades de informação; classificar objetivos e fatores críticos de sucesso (ranking); conectar fatores críticos de sucesso aos objetivos e as necessidades de informação aos fatores críticos de sucesso; e classificar necessidades de informação (ranking).
3.6.1.4 ESTÁGIO IV – CONSOLIDAÇÃO DE INDICADORES
Neste estágio, é realizada uma revisão dirigida com o grupo de executivos entrevistados para rever os objetivos, fatores críticos de sucesso, problemas e necessidades de informação, assim como confirmada a classificação (ranking) desses objetos.
As atividades destes estágio são: conduzir sessão de revisão dirigida; revisar fórmulas de controle de exceção; e revisar documento da sessão de revisão dirigida.
3.6.1.5 ESTÁGIO V – DESENVOLVIMENTO DE PROTÓTIPOS
São realizadas as atividades de desenho de telas e estruturas de navegação do sistema. É construído um protótipo para que os executivos possam ter uma visão mais próxima possível do que será o sistema.
As tarefas deste estágio são: definir ambientes e padrões de desenho; desenvolver protótipo; desenhar estrutura de drill-down; e obter aprovação do protótipo.
A conclusão desta etapa representa a definição final do formato do sistema sob a perspectiva do usuário.
14
4 UML – UNIFIED MODELING LANGUAGE
4.1 HISTÓRICO
Em outubro de 1995, Grady Booch e Jim Rumbaugh juntaram forças e criaram a Rational Corporation. Os dois foram os criadores das metodologias Booch e OMT (Object Modeling Technique). Lançaram então o Modelo Unificado (como foi chamado a princípio). Ainda neste mesmo outubro, Ivar Jacobson juntou-se a equipe de unificação fundindo o método OOSE (Object Oriented Software Engeneering), também chamado de Objectory [JAC1999].
Segundo MUL[1997], os respectivos trabalhos dos três mais respeitáveis experts da modelagem orientada à objetos (Grady Booch, Ivar Jacobson e Jim Rumbaugh) representavam diferentes aspectos do mesmo problema, então eles resolveram unir seus esforços para dar início a um processo de unificação. Dentro desse esforço coletivo, ocorreram as unificações dos métodos Booch – de Grady Booch, OOSE – de Ivar Jacobson, e OMT – de Jim Rumbaugh, e a incorporação de idéias de outros metodologistas.
Como autores, Booch, Rumbaugh e Jacobson estavam motivados a criar uma linguagem de modelagem unificada que tratasse de assuntos de escala inerentes a sistemas complexos e de missão crítica, que se tornasse poderosa suficiente para modelar qualquer tipo de aplicação de tempo real, cliente/servidor ou outros tipos de softwares padrões [JAC1999].
A primeira versão da descrição do Unified Method foi apresentada em outubro de 1995, no documento intitulado Unified Method V0.8. Este documento foi então distribuído na comunidade usuária, a qual retornou uma série de comentários que foram considerados pelos “unificadores”, e impulsionaram a versão 0.9 do mesmo documento (junho/1996). Porém, somente a versão 0.91 (outubro de 1996) é que trouxe uma evolução significativa ao Unified Method. Então houve uma modificação substancial no foco da unificação, onde a definição de uma linguagem universal para modelagem orientada à objetos passou a ser o primeiro objetivo. O Unified Method foi transformado então em UML (Unified Modeling Language) [MUL1997].
Em 1996, segundo [RAT1997] estava claro que a UML era percebida como um elemento básico na estratégia de várias grandes corporações. Foi então criado um consórcio de parceiros para trabalhar na definição da versão 1.0 da UML. Entre outras, pode-se destacar: HP, i-Logix, IBM, ICON Computing, Microsoft, Oracle, Rational Software e Unisys. Com a colaboração dos parceiros surge então a versão 1.0 da UML, a qual foi submetida para avaliação do OMG – Object Management Group (que segundo [BAR1997], possui, entre outras, a função de estabelecer padrões de objetos), para suas considerações.
Naquele mesmo momento, dentro da OMG, um outro grupo de técnicos e metodologistas se juntava para propor unificações e padrões de interoperabilidade entre produtos orientados à objetos. Esse grupo foi comandado por Mary Loomis da HP e James Odell [RAT1997].
Iniciava-se, dessa forma, a participação da OMG, que convocou a comunidade a apresentar propostas para unificação de métodos orientados à objetos. Surge então outra
15
proposta capitaneada pela Platinum (empresa emergente no mercado americano e logicamente preocupada com o ganho de visibilidade da concorrente Rational), denominada OML – Open Modeling Language. Porém, em maio de 1997, a Platinum anuncia a sua retirada do projeto OML e adere ao grupo de parceiros da UML [BAR1997].
Contudo, de acordo com [RAT1997], a UML versão 1.0 foi somente para responder às solicitações da OMG, e apenas depois dos parceiros da UML, durante alguns meses, é que foi produzida a versão 1.1 da UML. Essa liberação esclarecia algumas semânticas e incluía algumas novas contribuições. Então a UML foi (em setembro de 1997) novamente submetida ao OMG.
Enfim, como a notação da UML foi projetada para servir como uma linguagem de modelagem orientada à objetos, indiferente ao método de desenvolvimento, ela pode substituir – sem perda de informação – as notações de métodos como Booch, OMT e OOSE [MUL1997].
Todavia, todo esse histórico da evolução da UML pode ser melhor visualizado graficamente, através da figura 3:
Figura 3: Resumo do histórico da UML.
Fonte: adaptado de [MUL1997].
4.2 CONCEITOS
Unified Modeling Language (Linguagem de Modelagem Unificada) – UML, pode ser definida como uma linguagem para especificação, visualização, construção e documentação de artefatos de sistemas de software. Ela representa uma coleção das melhores experiências na
Publicação da UML 1.1 (09/97) UML 1.1 Publicação da UML 1.0 (01/97) UML 1.0 (06/96) e (10/96) UML 0.9 e 0.91
public UML partners’ feedback Expertise OOPSLA ’95 Unified Method 0.8 Booch ’93 OMT-2 Outros Métodos Booch ’91 OMT-1 OOSE
Industrialização
Padronização
Unificação
Fragmentação
16
área de modelagem de sistemas orientados à objetos, as quais têm obtido sucesso na modelagem de grandes e complexos sistemas [JAC1999].
Ela possui o propósito geral unificado de ser uma linguagem de modelagem gráfica para desenvolvimento orientado à objetos – em particular análise e projeto de objetos, e possui a característica de ser projetada com uma arquitetura de metamodelagem, o que permite que ela seja estendida [RAT1997].
Segundo o mesmo [RAT1997], Booch, Rumbaugh e Jacobson adotaram quatro metas para o processo de unificação:
a) representar sistemas complexos (em vez de somente porções de software) usando conceitos de unificação;
b) estabelecer uma ligação explícita entre conceitos e código executável; c) levar em conta os fatores de escala que são inerentes aos sistemas complexos e
críticos; d) criação de uma linguagem de modelagem utilizável por homens e máquinas.
De acordo com [BAR1997], com a unificação desses métodos de modelagem, líderes no mercado de desenvolvimento de softwares orientados à objetos, a UML provê a base para um comum, estável, e expressivo método de desenvolvimento orientado à objetos, sendo, consequentemente, o sucessor direto e mais compatível dos métodos que foram unificados.
Segundo [FUR1998], a UML pode ser utilizada para: a) mostrar as fronteiras de um sistema e suas funções principais utilizando atores e
casos de uso; b) ilustrar a realização de casos de uso com diagramas de interação; c) representar uma estrutura estática de um sistema utilizando diagramas de classes; d) modelar o comportamento de objetos através de diagramas de transição de estado; e) revelar a arquitetura de implementação física com diagramas de componentes e de
implementação; f) estender sua funcionalidade através de esteriótipos.
A UML é uma linguagem de modelagem, não uma metodologia. Ela vai além de uma simples padronização em busca de uma notação unificada, uma vez que contém conceitos novos que não são encontrados em outros métodos orientados à objeto. A UML recebeu influência de técnicas de negócios (fluxogramas), modelagem de objetos e componentes e incorporou idéias de vários autores [JAC1999].
4.3 CARACTERÍSTICAS
O modo para descrever os vários aspectos de modelagem pela UML é através da notação definida pelos seus vários diagramas. Modelar um sistema complexo é uma tarefa extensiva, sendo necessária a descrição de vários aspectos diferentes incluindo o funcional (estrutura estática e interação dinâmica), não funcional (tempo de processamento, confiabilidade, produção) e organizacional (organização do trabalho, mapeamento e código). Cada visão é descrita em um número de diagramas que contem informações enfatizando um aspecto particular do sistema. Assim, analisando o sistema através de visões diferentes, é possível concentrar-se em um aspecto de cada vez [JAC1999].
17
No início da definição da UML, foi necessário que houvesse uma concordância quanto a importância relativa de cada conceito fundamental de modelagem orientada à objetos. Chegando-se a essa concordância, seria possível implementar as trocas dos artefatos do processo de desenvolvimento, as quais ocorrem entre diferentes partes envolvidas num projeto, e selecionar uma representação gráfica, da qual a sintaxe deveria ser simples, intuitiva e expressiva [MUL1997].
Para facilitar esta tarefa, e para ajudar a formalizar a UML, foi utilizada a metamodelagem para realizar a formalização de todos os conceitos da mesma [MUL1997]. Em outras palavras, pode-se dizer que o metamodelo UML usa um subconjunto da notação e semântica da UML para especificar ela própria, similarmente ao que ocorre com um compilador que é utilizado para compilar ele próprio [RAT1997].
De acordo com [RAT1997], a UML possui uma arquitetura de metamodelo de quatro camadas, as quais são:
a) meta-metamodelo; b) metamodelo; c) modelo; d) objetos do usuário.
Segundo [RAT1997], esta arquitetura provê a infraestrutura para definição das semânticas precisas requeridas pelos modelos complexos. Há várias outras vantagens associadas com esta abordagem:
a) ela valida construções centradas pela aplicação dos metamodelo recursivamente para sucessivas camadas;
b) ela provê uma base arquitetônica para definição de futuras extensões do metamodelo UML;
c) ela fornece uma base arquitetônica para alinhamento do metamodelo UML com outros padrões baseados numa arquitetura de metamodelo de quatro camadas.
Quando a camada de metamodelo torna-se muito extensa ou complexa, a mesma pode ser particionada em packages, que são pacotes lógicos da UML e servem para incrementar a modularidade da linguagem.
4.4 DIAGRAMAS
Segundo [BAR1997], para suprir o seu propósito geral, que é o de ser uma linguagem de modelagem gráfica para desenvolvimento orientado à objetos (para as fases de análise e projeto), a UML disponibiliza uma série de diagramas para que seja possível levantar a especificação dos requisitos, a estrutura estática, a parte dinâmica ou comportamental, e os aspectos de implementação do sistema.
Seguindo o propósito deste trabalho, a seguir serão apresentados mais detalhadamente os diagramas de Classes e de Casos de Uso.
18
4.5 DIAGRAMA DE CLASSES
O diagrama de classe é a essência da UML, resultado de uma combinação de diagramas propostos pela OMT, Booch e vários outros métodos. Trata-se de uma estrutura lógica estática em uma superfície de duas dimensões, mostrando uma coleção de elementos declarativos de modelo, como classes, tipos e seus respectivos conteúdos e relações. Há quatro tipos de principais relacionamentos no diagrama de classes [JAC1999]. Os quais veremos a seguir:
a) Generalização / Especificação: Indica um relacionamento de classes mais geral e mais específico (respectivamente superclasse e subclasses). Conhecido também como herança ou classificação, conforme apresentado na figura 4:
Figura 4 – Exemplo de relacionamento generalização/especificação.
Fonte: Adaptado de [JAC1999]
b) Agregação: Usada para detonar relacionamentos todo/parte, como apresentado na figura 5: Figura 5 – Exemplo de relacionamento de agregação.
19
Fonte: Adaptado de [JAC1999]
c) Associação: Utilizada para detonar relacionamentos entre classes não correlatas. Por exemplo, um cliente pode alugar uma fita de vídeo, conforme apresentado na figura 6.
Figura 6 – Representação de uma associação.
Fonte: Adaptado de [JAC1999] d) Dependência: É um relacionamento entre classes, uma independente e outra dependente, onde uma mudança no elemento nas classes independentes afetará as classes dependentes, conforme figura 7.
Figura 7 – Representação de uma dependência. Fonte: Adaptado de [JAC1999]
20
4.5.1 CLASSE
[JAC1999] define classe como a representação de um conjunto de coisas reais ou abstratas reconhecidas como sendo do mesmo tipo por compartilhar as mesmas características de atributos, operações, relações e semântica. Os conceitos de classe e objeto são intercalados, já não se pode falar de um objeto sem mencionar a que classe ele pertence. Para [RAT1997], uma classe é o descritor para um conjunto de objetos com estrutura, comportamento e relacionamentos similares.
Ela é representada por um retângulo de compartimentalização, o qual possui três compartimentos. O primeiro compartimento, contém o nome da classe, o segundo os atributos e o último as operações da classe. Sendo que a exibição destes dois últimos pode ser suprimida – o que não significa que não há atributos ou operações na classe ([MUL1997]).
Um exemplo de classe, na UML, pode ser visto na figura 8:
Figura 8 – Exemplo de classe
Fonte: Adaptado de [JAC1999]
4.5.2 ATRIBUTOS
Atributo é a menor unidade que em si possui significância própria e interrelacionada com o conceito lógico da classe à qual pertence. Os detalhes de expressões de atributos não
21
são especificados na UML, ficando a cargo da sintaxe de expressões suportada pelo ambiente de desenvolvimento da aplicação ([JAC1999]).
4.5.3 OPERAÇÕES
Segundo [JAC1999], na UML, um serviço de classe ou comportamento resultante de um procedimento algorítmico é denominado operação. É importante ressaltar que existem diferenças entre operações e métodos: uma operação é algo invocado por um objeto (chamada) enquanto um método é a implementação de uma operação.
De acordo com [JAC1999], as operações podem ainda ser classificadas de uma forma genérica como:
a) construtoras: operações que criam e/ou inicializam o estado de um objeto; b) seletoras: operações que tem acesso mas não podem alterar o valor ou estado dos
objetos; c) modificadoras: operações que alteram o valor ou estado dos objetos; d) de interação: operações que permitem o acesso de partes do objeto em uma ordem
pré-definida; e) destrutoras: operações que destroem/desabilitam objetos.
4.6 DIAGRAMA DE CASOS DE USO
Os diagramas de casos de uso descrevem um comportamento de um sistema do ponto de vista do usuário. Eles permitem que sejam definidos os limites do sistema e os relacionamentos entre o sistema e o ambiente ([MUL1997]). Eles expressam a funcionalidade do sistema, a qual se manifesta em resposta a alguma interação de um ator externo ao mesmo ([RAT1997]).
Segundo [JAC1999], diagramas de casos de uso fornecem um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível de funcionalidade intencional mediante o recebimento de um tipo de requisição de usuário.
O propósito primário dos casos de uso, para o mesmo [JAC1999] é: a) descrever os requerimentos funcionais do sistema de maneira consensual entre
usuários e desenvolvedores de sistemas; b) fornecer uma descrição consistente e clara sobre as responsabilidades que devem
ser cumpridas pelo sistema, além de formar a base de desenho; c) oferecer as possíveis situações do mundo real para o teste do sistema.
Um diagrama de casos de uso é um gráfico constituído de atores, um conjunto de use cases (casos de uso) incluído por um limite de domínio, associações de comunicação ou de participação entre os atores e os casos de uso, e generalizações entre os casos de uso ([RAT1997]), um exemplo deste diagrama pode ser visto na figura 9:
22
Figura 9 – Exemplo de um diagrama de caso de uso
Fonte: Adaptado de [JAC1999]
O propósito de um caso de uso é definir o comportamento de uma classe passiva sem revelar sua estrutura interna. Do ponto de vista pragmático, um caso de uso pode ser usado para especificar as necessidades e funcionalidades oferecidas por uma classe. A classe especificada pode ser um sistema ou qualquer elemento do modelo que contém comportamento em um modelo de sistema ([JAC1999]).
4.6.1 ATOR
Um ator define um conjunto coerente de papéis que os usuários de uma entidade, sejam eles pessoas ou coisas, podem representar quando estiverem interagindo com a entidade em questão ([RAT1997]).
De acordo com [JAC1999], o mundo externo é representado por atores que desempenham papéis. Um ator é um agente que interage com o sistema, um tipo de usuário ou categoria com papel definido, podendo incluir seres humanos, máquinas, dispositivos ou outros sistemas (atores não precisam ser necessariamente pessoas, mesmo sendo representados por um croquí). É importante ressaltar que um ator representa um papel, e não um usuário individual de um sistema – a ênfase em papéis é importante: um ator pode representar muitos papéis e um papel pode ser representado por muitos atores.
Para [RAT1997], um ator define um conjunto coerente de papéis que os usuários de uma entidade, sejam eles pessoas ou coisas, podem representar quando estiverem interagindo com a entidade em questão.
A determinação dos atores facilita e especificação dos limites do sistema numa maneira incremental, pois no início os limites parecem confusos, mas a medida que os níveis inferiores de casos de uso são implementados, eles vão tornando-se mais precisos. Essa delineação de atividade é muito importante para se saber o que faz parte do sistema a ser desenvolvido e o que não faz ([MUL1997]).
23
O mesmo [MUL1997], classifica os atores em quatro categorias distintas: a) atores principais: pessoas que usam as funções principais do sistema. Exemplo: um
cliente que realiza um saque num caixa eletrônico, num sistema bancário; b) atores secundários: pessoas que executam tarefas de manutenção ou administração.
Exemplo: o funcionário que repõe o dinheiro nos caixas eletrônicos, num sistema bancário;
c) hardware externo: os dispositivos de hardware inevitáveis que são parte do domínio da aplicação e devem ser usados. Ele tem nada a ver com o computador no qual a aplicação é executada, mas pertence a outros periféricos de hardware. Exemplo: o caixa eletrônico, num sistema bancário;
d) outros sistemas: os outros sistemas com o qual o sistema deve interagir.
O ator possui um nome e pode comunicar-se com um conjunto de casos de uso, sendo que o seu nome deve descrever o papel representado pela pessoa ou coisa que está interagindo com o sistema ([RAT1997]).
4.6.2 CASO DE USO
Segundo [JAC1999], o propósito de um caso de uso é definir o comportamento de uma classe passiva sem revelar sua estrutura interna. Do ponto de vista pragmático, um caso de uso pode ser usado para especificar as necessidades e funcionalidades oferecidas por uma classe. A classe especificada pode ser um sistema ou qualquer elemento do modelo que contém comportamento em um modelo de sistema. Eles são abstrações do diálogo entre os atores e o sistema, descrevendo as interações (cenários) potenciais entre os mesmos ([MUL1997]).
Cada caso de uso especifica um serviço que a entidade provê aos seus usuários, isto é, um modo específico de usar a entidade. Ele especifica as interações entre os usuários e a entidade tão bem quanto as respostas executadas pela entidade (assim que elas são percebidas do lado de fora da entidade, elas são especificadas) ([RAT1997]).
De acordo com [MUL1997], existem alguns pontos que podem ser observados para a construção dos casos de uso, os quais estão relacionados abaixo:
a) o caso de uso é uma interação entre um ator e um sistema na forma de fluxo de eventos. Desta forma, a descrição do caso de uso deve estar focalizada na identificação do “o que” deve ser feito no caso de uso, e não no “como” deve ser feito;
b) um caso de uso deve ser simples, inteligível e descrito de maneira clara e concisa. Quando um caso de uso ficar muito complexo, muito entrelaçado, ou se várias partes dele demonstram ser independentes, é interessante estudar a possibilidade de fragmentá-lo;
c) deverá possuir um evento de início (o qual dispara o caso de uso) e o evento de finalização (o qual pára o caso de uso);
d) deverá conter a interação entre o caso de uso e os atores, pois descreve claramente o que está do lado de dentro do sistema e o que está do lado de fora do sistema; e as informações que são trocadas, ou seja, os parâmetros da interação;
e) é importante descrever quando o sistema requer uma informação interna ou externa, e quando ele grava a informação internamente ou externamente;
24
f) as situações opcionais devem ser representadas numa maneira uniforme em todos os casos de uso.
4.6.3 INTERAÇÃO EM CASO DE USO
O ator comunica-se com o sistema através do envio e recebimento de mensagens, sendo que um caso de uso é sempre iniciado a partir do momento que um ator envia sua mensagem (estímulo). As seguintes interações são importantes dentro de um diagrama de casos de uso, de acordo com [JAC1999]:
a) Communicates (comunicação): um ator comunica-se com o caso de uso, assim, cada participação sua é mostrada conectando o ator ao caso de uso. Representado por uma linha sólida que liga o ator ao caso;
b) Extends (extensão): são usadas geralmente para mostrar situação que geram exceções e casos especiais que aumentariam o número de casos de uso no modelo. É desenhada através de uma seta de generalização etiquetada com o stereotype <<extends>>, do caso de uso que fornece a extensão para o caso de uso básico;
c) Uses (uso): Quando um número de casos de uso tem um comportamento comum, este caso pode ser modelo em único caso de uso, que é utilizado por outros casos. A representação é uma seta de generalização do caso de uso que faz o uso ao caso de uso que é usado, etiquetado com o stereotype <<uses>>.
Como regra geral, [JAC1999], coloca que se deve empregar relacionamento de extensão quando estiver descrevendo uma variação de um comportamento normal, e relacionamento de uso quando estiver repetindo um comportamento em dois casos de uso distintos.
A figura 10, mostra um exemplo de um diagrama de caso de uso que faz uso dos três tipos de interações ou relacionamentos permitidos pela notação UML:
Figura 10 – Exemplo de diagrama de caso de uso com 3 tipos de interações
25
Fonte: Adaptado de [JAC1999]
MUL[1997] coloca alguns benefícios que podem ser destacados com a utilização do diagrama de casos de uso para a especificação de requisitos:
a) o levantamento de requisitos é iniciado de um ponto de vista mais simples, pois a organização da abordagem dos casos de uso é executada com respeito às interações de uma simples categoria de usuários (atores) em um determinado momento. Desta forma, ocorre um particionamento do conjunto de requisitos, reduzindo consideravelmente a complexidade da determinação de requisitos;
b) o formalismo dos casos de uso – baseados em linguagem natural – é acessível sem qualquer treinamento particular do usuário;
c) a terminologia usada para escrever casos de uso é a mesma que a terminologia empregada pelos usuários no seu dia-a-dia (uma vez que utilizam-se de linguagem natural como foi salientado no item anterior), portanto facilitam a expressão do resultado dos requisitos (evitam que o foco de interesse dos usuários seja desviado durante as etapas seguintes da modelagem);
d) os casos de uso ajudam os usuários a estruturar e articular seus desejos. Eles obrigam os usuários a definir a maneira na qual eles achariam bom interagir com o sistema, para especificar qual informação eles esperam trocar, e para descrever o que eles devem fazer para obter o resultado esperado. Assim favorecem a definição de um conjunto de especificações que realmente refletem requisitos do sistema.
26
5 ESPECIFICAÇÃO DO PROTÓTIPO
5.1 ESCOPO DO PROTÓTIPO
O protótipo tem um funcionamento simples, sendo dividido em três bases de dados, que contemplam os clientes, os fornecedores e os pedidos, respectivamente.
O arquivo de clientes armazena e disponibiliza as informações dos clientes, tais como: razão social, endereço, c.g.c., incr. est., telefones, último pedido, valor da última compra e etc.
O arquivo de fornecedores armazena e disponibiliza as informações dos fornecedores, tais como: razão social, endereço, c.g.c., insc. est., telefones, percentual de comissão e etc.
O arquivo de pedidos armazena e disponibiliza as informações referentes aos pedidos emitidos pelo representante, tais como: número do pedido, data, cliente, fornecedor, forma de pagamento, condições e local de entrega, quantidade pedida, descrição da mercadoria, preço e etc.
5.2 IMPLEMENTAÇÃO
Para a implementação deste protótipo, serão seguidos os 3 primeiros passos descritos pela metodologia de implementação de [MEL1990], apresentada na figura 11 abaixo:
Figura 11 – Metodologia da Prototipação
Fonte: Adaptado de [MEL1990].
5.2.1 NECESSIDADES DO USUÁRIO
Segundo [LIM1999] o processo de tomada de decisões estratégicas dentro das empresas requer muito dos executivos, e os mesmos para tomarem decisões acertadas necessitam estar sempre bem informados sobre tudo o que acontece dentro da empresa e também estar por dentro de tudo que esta acontecendo a seu redor, fora da empresa.
Este trabalho disponibilizará ao executivo, de uma maneira simplificada, informações referentes às suas vendas para que ele possa tomar as decisões estratégicas dentro da empresa fundamentado não somente em cima de dados internos, mas também com dados externos dando a ele uma visão holística sobre a empresa e seu cliente. Dados como o status do cliente perante a sua empresa, por exemplo, que pode assumir três valores: sem débito (quando o
1
Necessidades do usuário
2 Levantamento de requisitos
3 Desenvolvimento do protótipo
4 Demonstração do protótipo
5 Revisão do protótipo
6 Elaboração da documentação
7 Incorporação de esquemas
8 Implementação
27
cliente efetua compras a vista), em débito no prazo (quando o cliente efetuou uma compra com pagamento a prazo e ainda não vencido) ou em débito em atraso (quando o cliente efetuou uma compra, o prazo está vencido e o pagamento ainda não efetuado).
5.2.2 LEVANTAMENTO DE REQUISITOS
Na fase do levantamento de requisitos, serão obedecidas as especificações da UML, conforme apresentado no capítulo 4.
Uma visão mais ampla do funcionamento do protótipo com suas três bases de dados, pode ser melhor observada no diagrama de classes e no diagrama de casos de uso, dispostos nas figuras 12 e 13, respectivamente abaixo:
Figura 12 – Diagrama de Classes
São três classes (Clientes, Pedidos e Fornecedores), cada uma com os seus atributos, onde um pedido pode ser realizado por apenas um cliente e atendido por apenas um
28
fornecedor. Um cliente pode realizar nenhum ou vários pedidos e um fornecedor, pode atender a nenhum ou vários pedidos.
Figura 13 – Diagrama de Casos de Uso
Na figura 13, temos o ator (usuário) que é o responsável por manter clientes e fornecedores e também emitir os pedidos. Pedidos estes que são feitos por clientes e atendidos por fornecedores.
Uma outra situação, é o recebimento dos dados do protótipo por parte do usuário, que vem a complementar o diagrama de casos de uso, e pode ser vista na figura 14, abaixo:
Figura 14 – Diagrama de casos de uso
29
Conforme a figura 14, o usuário tem acesso aos relatórios emitidos pelo protótipo que os realiza com base nos cadastros de clientes, pedidos e fornecedores.
Uma outra forma de expressar o funcionamento do protótipo, exemplificando a emissão de um pedido, seria através de um diagrama de eventos e interações, conforme a figura 15:
Figura 15 – Diagrama de Eventos e Interações (emissão de pedidos)
5.2.3 DESENVOLVIMENTO DO PROTÓTIPO
Para o desenvolvimento do protótipo, após apuradas as necessidades do usuário e realizado o levantamento de requisitos, é necessária a definição do ambiente de desenvolvimento.
A escolha do ambiente de desenvolvimento das aplicações deve ser feita após várias considerações, incluindo-se desde o conhecimento de programação, requisitos da aplicação a ser desenvolvida, compatibilidade com código de sistemas existentes (ou herdados) até a integração com banco de dados e internet ([ALV1996]).
Como ambiente para o desenvolvimento deste protótipo foi utilizado o Delphi 5.0, por se tratar de um ambiente que possui uma linguagem de programação orientada a objetos,
Opção Emissão
Opção Emissão
Selecionar Cliente
Selecionar Cliente
Menu Pedidos
Selecionar Fornecedor
Selecionar Fornecedor
Preencher Campos
Preencher Campos
Clicar Botão OK
30
Pascal Object, a qual disponibiliza classes de objetos propícias à implementação, aliada ao banco de dados Paradox 7.0.
5.3 FUNCIONAMENTO DO PROTÓTIPO
O protótipo contém 4 itens de menu, os quais se denominam: Clientes, Fornecedores, Pedidos e Relatórios e o botão de Saída, conforme exibido na figura 16, abaixo:
Figura 16 – Tela principal do protótipo
O item Clientes disponibiliza o sub-item Cadastra, que deverá ser utilizado para incluir, consultar, alterar ou excluir os dados referentes aos clientes.
O item Fornecedores disponibiliza o sub-item Cadastra, que deverá ser utilizado para incluir, consultar, alterar ou excluir os dados referentes aos fornecedores.
O item Pedidos disponibiliza o sub-item Emissão que deverá ser utilizado para emitir, consultar, alterar ou excluir pedidos de clientes.
E finalmente, o item Relatórios que disponibiliza os sub-itens venda por Cliente, venda por Fornecedor, coMissões e cLientes . É importante salientar que neste item, todos os relatórios disponibilizados, oferecem a opção de visualização dos mesmos na tela do microcomputador sem a obrigatoriedade de impressão dos mesmos, o que torna os relatórios, também opções de consulta, ou ainda, a visualização de gráficos, referentes aos mesmos.
Em anexo, constam os relatórios disponibilizados pelo protótipo bem como, a emissão de um pedido.
31
5.3.1 CLIENTES
No menu Clientes, dentro da opção Cadastra, o código do cliente é fornecido automaticamente pelo protótipo para que seja feita a inclusão de um novo cliente, que se dará após o usuário preencher os campos solicitados na tela e clicar no botão OK, conforme apresentado na figura 17, abaixo:
Figura 17 – Tela de cadastro de clientes
Se o usuário desejar fazer alguma consulta aos dados do cliente, basta digitar o código do cliente que os dados respectivos ao mesmo são automaticamente trazidos à tela pelo protótipo para que sejam analisados ou até mesmo para que sejam feitas alterações cadastrais (depois clicando no botão OK).
Caso o usuário queira excluir um cliente do cadastro, basta para isso informar o código do mesmo (e os referidos dados são trazidos à tela, conforme explica o parágrafo anterior), pressionar o botão EXCLUIR e confirmar a deleção do mesmo, que será solicitada, por motivos de segurança (para evitar que o usuário delete um cliente involuntariamente).
Existe ainda nesta opção Cadastra, o botão CANCELAR, que serve para que o usuário aborte qualquer das opções acima com um simples “click” de mouse. E finalmente, o botão SAÍDA, que tem a função de sair da opção Cadastra e retornar à tela principal do protótipo.
32
5.3.2 FORNECEDORES
No menu Fornecedores, dentro da opção Cadastra, o código do fornecedor é gerado automaticamente pelo protótipo, possibilitando assim, que seja feita a inclusão de um novo fornecedor, que se concretizará após o usuário preencher os campos solicitados na tela e clicar no botão OK, conforme apresentado na figura 18, abaixo:
Figura 18 – Tela de cadastro de fornecedores
Caso deseje, o usuário, fazer alguma consulta aos dados de um fornecedor, basta para isso, digitar o código do fornecedor no campo indicado que os dados respectivos ao mesmo são automaticamente trazidos à tela pelo protótipo para que sejam analisados ou até mesmo para que sejam realizadas as alterações necessárias (clicando posteriormente no botão OK).
Se o usuário desejar excluir um fornecedor do cadastro, será necessário para isso que se informe o código do referido fornecedor (que os dados pertinentes ao mesmo serão automaticamente trazidos à tela, pelo protótipo). Feito isso, o próximo passo é pressionar o botão EXCLUIR e finalmente, confirmar a deleção do mesmo, que será solicitada pelo protótipo, por motivos de segurança (para evitar que um fornecedor seja indevidamente excluído).
33
Existe ainda na opção Cadastra do menu Fornecedores, o botão CANCELAR, que tem por função, proporcionar ao usuário a opção de abortar qualquer das operações acima com um simples “click” de mouse. E finalmente, também possui o botão SAÍDA, que tem a função de sair da opção Cadastra e retornar à tela principal do protótipo.
5.3.3 PEDIDOS
No menu Pedidos, há somente a opção Emissão, que tem por função principal a emissão de pedidos de clientes à fornecedores cadastrados e possui e tela apresentada na figura 19, abaixo:
Figura 19 – Tela emissão de pedidos.
Para que a emissão de um pedido seja processada, ao entrar na opção Emissão, o número do pedido é automaticamente fornecido pelo protótipo, possibilitando ao usuário iniciar o processo da emissão informando o nome de busca do cliente (e depois clicando sobre
34
o mesmo para selecioná-lo) e o nome de busca do fornecedor (também selecionando-o posteriormente com o mouse).
Uma vez devidamente selecionados cliente e fornecedor, basta ao usuário preencher os demais campos disponíveis na tela e confirmar a emissão do pedido clicando no botão OK, ou se preferir imprimir automaticamente o mesmo, clicando no botão IMPRIME (que além de imprimir confirma o pedido). Existe também a opção do usuário configurar a impressora antes da impressão, clicando no botão IMPRESSORA. Já o botão VISUALIZA, fornece ao usuário uma cópia do pedido na tela, para apreciação do mesmo antes ou depois de sua impressão, conforme apresentado na figura 20:
Figura 20 – Exemplo de um pedido visualizado na tela.
Caso deseje, o usuário, alterar os dados de um pedido emitido anteriormente, basta digitar no campo devido o número correspondente ao mesmo, que o protótipo traz à tela todos os dados do referido pedido para que sejam então realizadas as devidas alterações. Feito isso, o usuário deve confirmar as alterações clicando no botão OK. Ou, se o usuário desejar que seja feita a exclusão deste pedido, deve clicar no botão EXCLUIR, e consequentemente,
35
confirmar a deleção do mesmo quando o protótipo a requisitar, por medida de segurança, para evitar que um pedido indevidamente seja excluído.
Para abortar qualquer dessas operações, o protótipo disponibiliza ao usuário o botão CANCELAR, que possui essa função. E finalmente, para sair desta opção, o usuário deve pressionar o botão SAÍDA.
5.3.4 RELATÓRIOS
Como já foi colocado anteriormente, o menu Relatórios, disponibiliza quatro sub-itens: venda por Cliente, venda por Fornecedor, coMissões e cLientes, os quais serão descritos individualmente.
5.3.4.1 VENDA POR CLIENTE
Nesta opção, o usuário deve digitar apenas o nome de busca do cliente, e fornecer o intervalo de datas entre as quais o mesmo deseja saber quais foram os pedidos realizados por aquele determinado cliente, conforme apresenta a figura 21, abaixo:
Figura 21 – Vendas por cliente.
Uma vez informados os dados, o usuário pode clicar no botão VISUALIZA para que o protótipo traga à tela, todos os pedidos realizados por aquele determinado cliente no devido período de tempo informado. Abaixo, na figura 22, temos um exemplo da visualização deste relatório:
36
Figura 22 – Visualização do relatório Vendas por cliente.
Para imprimir este relatório, deve o usuário clicar no botão IMPRIME, ou caso desista da impressão, clicar no botão CANCELA. Existe ainda a possibilidade do usuário configurar a impressora antes da impressão deste relatório, para isso, deve o usuário clicar no botão IMPRESSORA. E finalmente, para sair desta opção, basta ao usuário somente clicar no botão SAÍDA.
5.3.4.2 VENDA POR FORNECEDOR
Nesta opção, o usuário deve digitar apenas o nome de busca do fornecedor, e informar o intervalo de datas entre as quais o mesmo deseja saber quais foram os pedidos realizados para aquele determinado fornecedor, processo semelhante para a obtenção do relatório de venda por cliente, conforme apresentado na figura 23:
37
Figura 23 – Visualização da tela de relatório de vendas por fornecedor:
Sendo assim, uma vez informados os dados, o usuário pode nesta opção também, clicar no botão VISUALIZA para que o protótipo traga à tela, todos os pedidos emitidos para aquele determinado fornecedor no devido período de tempo informado. É apresentado abaixo, na figura 24, um exemplo da visualização deste relatório:
Figura 24 – Visualização do relatório Vendas por fornecedor.
Para imprimir este relatório, o usuário deve clicar no botão IMPRIME, ou caso desista da impressão, clicar no botão CANCELA. Existe também a possibilidade do usuário
38
configurar a impressora antes da impressão deste relatório, caso deseje, para isso, deve o usuário clicar no botão IMPRESSORA. E finalmente, para sair desta opção, basta ao usuário simplesmente clicar no botão SAÍDA.
Porém, nesta opção, está disponibilizado um gráfico, que também tem seus dados de acordo com as datas selecionadas. Para ter acesso ao mesmo, basta ao usuário, após selecionar o fornecedor e as datas (conforme figura 23), clicar no botão gráfico e será apresentado na tela o referido gráfico, conforme figura 25:
Figura 25 – Gráfico de Vendas por Fornecedor
5.3.4.3 COMISSÕES
Para a obtenção do relatório de comissões, o usuário deve digitar apenas o nome de busca do fornecedor, e informar o intervalo das datas entre as quais o mesmo deseja saber quais são os valores referentes às comissões daquele determinado fornecedor. Conforme pode ser observado na figura 26, abaixo:
39
Figura 26 – Tela do relatório de Comissões.
Uma vez informados estes dados, o usuário deve clicar no botão VISUALIZA, que fará com que o protótipo traga à tela, todos os pedidos emitidos para aquele determinado fornecedor com os respectivos valores de comissões à receber de cada pedido, no devido período de tempo informado, bem como a totalização das comissões ao final do relatório. Abaixo, é apresentado na figura 27, um exemplo da visualização deste relatório:
Figura 27 – Visualização do relatório de Comissões.
40
Para imprimir este relatório, basta ao usuário clicar no botão IMPRIME, ou caso desista da impressão, clicar no botão CANCELA. Existe também a possibilidade do usuário configurar a impressora antes da impressão deste relatório, devendo para isto, clicar no botão IMPRESSORA. E finalmente, para sair desta opção, basta ao usuário simplesmente clicar no botão SAÍDA.
Porém, nesta opção, também está disponibilizado um gráfico, que também tem seus dados de acordo com as datas selecionadas. Para ter acesso ao mesmo, basta ao usuário, após selecionar o fornecedor e as datas (conforme figura 26), clicar no botão gráfico e será apresentado na tela o referido gráfico de comissões, conforme figura 28:
41
Figura 28 – Gráfico de Comissões por Fornecedor
5.3.4.4 CLIENTES
Para a obtenção do relatório de clientes, o usuário deve informar ao protótipo apenas o nome da cidade desejada. Conforme apresentado na figura 29, abaixo:
Figura 29 – Tela do Relatório de Clientes.
42
Uma vez informada a cidade, o usuário deve clicar no botão VISUALIZA para que o protótipo traga à tela todos os dados de todos os clientes referidos àquela cidade. Conforme apresenta a figura 30:
Figura 30 – visualização do relatório de clientes.
Para imprimir este relatório, deve o usuário clicar no botão IMPRIME, ou caso o usuário não queira imprimir o relatório, basta clicar no botão CANCELA. Existe nesta opção também a possibilidade do usuário configurar a impressora antes da impressão deste relatório, bastando para isto ao usuário, clicar no botão IMPRESSORA. E finalmente, para sair desta opção, somente clicar no botão SAÍDA.
43
6 CONCLUSÕES
Nos dias de hoje, a competitividade do mercado faz com que os mais variados setores da indústria e do comércio busquem na evolução tecnológica, uma forma de sobrevivência.
No caso dos representantes comerciais, que são profissionais liberais e prestadores de serviços à grandes instituições, a competitividade elevada dos últimos anos não tem deixado muito espaço para que estes profissionais reciclem-se a nível de conhecimento no campo da informática.
Porém, segundo [DAL1998], a não utilização de sistemas de informações como recursos estratégicos, leva o executivo, muitas vezes, a administrar por impulsos, ou baseado em modismos.
E sendo assim, os representantes que não se informatizarem, correm aqui um grande risco. O de se deixar levar por modismos ou impulsos não tomando assim a decisão mais acertada.
Conforme apresentado neste trabalho, um Sistema de Informações Executivas não exige dos administradores um profundo conhecimento computacional. Muito pelo contrário, deve ser desenvolvido para atender especificamente as necessidades do cliente. Com estas conclusões, não restam dúvidas de que o mais apropriado para os representantes comerciais, profissionais com pouco conhecimento computacional e pouco tempo para aprendizado, porém deficitários e ávidos por informações, realmente são os E.I.S.
Nos coloca [STA1998] que o valor da informação está diretamente ligado à maneira como ela ajuda os tomadores de decisões a atingirem as metas da organização, devendo esta informação ter como características: precisão, flexibilidade, confiabilidade, relevância, simplicidade e estar disponível no momento em que for necessária.
Aliando um E.I.S. com as técnicas da UML que descreve, por exemplo, em seus diagramas de casos de uso, as ações de um usuário, facilitando assim um maior entendimento a nível de usuário do que deve disponibilizar o sistema (e isso é também um fato relevante para os E.I.S.), foi encontrada uma harmonia perfeita para disponibilizar aos representantes, as informações com as características solicitadas no parágrafo acima.
Outro ponto que facilitou o desenvolvimento deste trabalho, se deve ao fato de que eu mesmo, sou um representante comercial há alguns anos e por isso conheço bem as necessidades da classe.
Com relação ao protótipo, pode-se dizer que ele atingiu o seu objetivo primário, que era o de ser uma ferramenta capaz de auxiliar nas tarefas administrativas de representantes comerciais do ramo têxtil, de forma prática. Englobando as técnicas da UML para o seu desenvolvimento, como o diagrama de classe (figura 13) e os diagramas de casos de uso (figuras 14 e 15), e atendendo as exigências de um sistemas de informações executiva tornando-se um mecanismo computadorizado que fornece aos executivos as informações necessárias para gerenciar o negócio, conforme [FUR1994].
44
6.1 SUGESTÕES
Como propostas para trabalhos futuros sugere-se:
a) a contemplação na emissão do pedido, de uma opção para que o mesmo possa ser enviado via e-mail ao fornecedor;
b) a implementação de um relatório de clientes inadimplentes;
c) a implementação de gráficos dos status dos clientes;
d) a inclusão dos demais gráficos ainda não contemplados pelo protótipo, como po exemplo, o da porcentagem de fornecedores em relação ao total de vendas e comissões.
45
ANEXOS
46
47
48
49
50
REFERÊNCIAS BIBLIOGRÁFICAS
[ACI2000] ACIB, BADESC, FURB e Hering Têxtil S/A. Fórum de Desenvolvimento Regional do Médio Vale do Itajaí. Disponível em http://www.furb.rct-sc.br/forummvi/port (Maio/25/2000 16:26)
[ALV1996] ALVES, Abel. Prospecção. Revista Developers Magazine, Rio de Janeiro : Axcel Books do Brasil Editora Ltda., n.4, p.48, dez. 1996.
[BAR1997] BARBIERI, Carlos. A unificação dos métodos de orientação a objetos. Revista Developers Magazine, Rio de Janeiro : Axcel Books do Brasil Editora Ltda., n.12, p.20-24, ago. 1997.
[DAL1998] DALFOVO, Oscar. Desenho de um modelo de sistema de informação estratégico para a tomada de decisão nas pequenas e médias empresas do setor têxtil de Blumenau. Blumenau, 1998. Dissertação (Mestrado em Administração) Centro de Ciências Sociais Aplicadas, FURB.
[FUR1994] FURLAN, José Davi, IVO, Ivonildo da Motta, AMARAL, Francisco Piedade. Sistemas de informações executivas. São Paulo : Makron Books, 1994
[FUR1998] FURLAN, José Davi. Modelagem de objetos através da UML – The unified modeling language. São Paulo : Makron Books, 1998.
[JAC1999] JACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James. Unified Software Development Process. Addison-Wesley Pub Co, 1999.
[KOR1993] KORMANN Marlon. Sistema de Informações para Executivos: estudo e protótipo aplicado à área de investimento e compras. Blumenau, 1993. Monografia (Bacharelado em Ciências da Computação) Centro de Ciências Exatas e Naturais, FURB.
[LAU1997] LAUDON, K. C. e LAUDON, J. P. Management Information Systems, 4ª ed., Upper Saddle River (N.J.) : Prentice Hall, 1997.
[LIM1999] LIMA, Fernando A. de. Protótipo de um sistema de informações executivas com módulo inteligente. Blumenau, 1999. Monografia (Bacharelado em Ciências da Computação) Centro de Ciências Exatas e Naturais, FURB.
[MAC1996] MACHADO, Carlos. Como dar o tiro certo na hora de decidir. Informática Exame, São Paulo, p.48-55, Março, 1996
[MAR1999] MARIANO, Márcia. 1999 - Panorama do atual contexto. Revista Têxteis Interamericanos, São Paulo : EBT – Editora Brasil Têxtil Ltda., n.34, p.46, Out/Nov/Dez, 1999.
[MEL1990] MELENDEZ, Rubem Filho. Prototipação de sistemas de informações : fundamentos, técnicas e metodologias. São Paulo : Livros técnicos e científicos, 1996.
[MUL1997] MULLER, Pierre-Alain. Instant UML . Canadá : Wrox Press Ltd., 1997.
51
[NAU1998] NAU, Rodrigo Dadam. Protótipo de uma ferramenta CASE para a fase de análise da proposta UML. Blumenau, 1998. Monografia (Bacharelado em Ciências da Computação) Centro de Ciências Exatas e Naturais, FURB.
[OLI1992] OLIVEIRA, Djalma de Pinho Rebouças. Sistemas de informações gerenciais. São Paulo : Atlas, 1992.
[PRA1994] PRATES, Maurício. Conceituação de Sistemas de Informação do Ponto de Vista do Gerenciamento. Revista do Instituto de Informática, PUC-CAMP, Março/Setembro, 1994.
[RAT1997] RATIONAL, Software Corporation. Unified Modeling Language, version 1.1 1997. Disponível em http://www.rational.com/uml (Maio/10/2000 15:10)
[SAL1994] SALVADOR, Jean Hélvio. Um protótipo de sistemas de informações executivas para a área de administração de vendas. Blumenau, 1994. Monografia (Bacharelado em Ciências da Computação) Centro de Ciências Exatas e Naturais, FURB.
[SKA2000] SKAF, Paulo. A indústria têxtil já fez a lição de casa. Jornal de Santa Catarina. n. 8.805, p.4A., 02 de Junho de 2000.
[STA1998] STAIR, Ralph M.. Princípios de Sistemas de Informação : Uma abordagem Gerencial. Rio de Janeiro : LTC, 1998.
[TAU1998] TAURION, Cezar. Sistemas de Gestão Empresarial. Revista Developer’s Magazine, Rio de Janeiro : ano 2, n. 20, p. 10-11, abr. 1998.