Introduo Ao Projeto e To de Sistemas de Infor

INTRODUO AO PROJETO E DESENVOLVIMENTO DE SISTEMAS DE INFORMAO
FEA/USP
Prof. ANTONIO GERALDO DA ROCHA VIDAL
Julho/1998
FEA/USP - EAD-451 Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal
SUMRIO
O CONCEITO DE SISTEMA DE INFORMAO .............................................................................................1 Introduo .......................................................................................................................................1 A Necessidade de Informao ..........................................................................................................1 O Conceito de Sistema .....................................................................................................................1 A Empresa como um Sistema ...........................................................................................................3 Sistemas de Informao ...................................................................................................................4 Componentes de um Sistema de Informao Automatizado ..............................................................8 NECESSIDADES DE INFORMAO ............................................................................................................8 Tipos de Informao ........................................................................................................................8 Informaes Externas ......................................................................................................................8 Informaes Internas .......................................................................................................................9 METODOLOGIA PARA IDENTIFICAO DAS NECESSIDADES DE INFORMAO............................................13 Etapa 1 Identificao dos Objetivos e dos Fatores Crticos de Sucesso.....................................13 Etapa 2 Levantamento das reas de Aplicao da Informtica.................................................15 Etapa 3 Consolidao das Aplicaes Identificadas .................................................................16 Etapa 4 Definio das Classes de Dados ..................................................................................16 Etapa 5 Priorizao das Aplicaes a serem Informatizadas.....................................................19 Resultado da Metodologia .............................................................................................................21 DEFINIO DOS REQUISITOS DE UM SISTEMA DE INFORMAO ...............................................................23 Introduo .....................................................................................................................................23 Relao de Requisitos do Sistema ..................................................................................................23 Grupo para Especificao do Sistema............................................................................................24 BASES DE DADOS .................................................................................................................................24 Introduo .....................................................................................................................................24 Estrutura de uma Base de Dados ...................................................................................................25 Chave Primria ou Identificadora..................................................................................................27 ndices de Acesso...........................................................................................................................27 Projeto de Bases de Dados.............................................................................................................29 ETAPAS DO PROJETO DE SISTEMAS........................................................................................................31 Introduo .....................................................................................................................................31 Etapa 1 Modelagem de Processos.............................................................................................31 Etapa 2 Modelagem de Dados ..................................................................................................31 Etapa 3 Normalizao ..............................................................................................................32 Etapa 4 Reconstruo do BPM e do RDM ................................................................................33 Etapa 5 Definio dos Mdulos do Sistema ..............................................................................33 IMPLEMENTAO DO SISTEMA..............................................................................................................34 Introduo .....................................................................................................................................34 Prototipao ..................................................................................................................................34 Prototipao de Descoberta...........................................................................................................35 Prototipao de Refinamento.........................................................................................................35 MODELO DE PROCESSOS DO NEGCIO (BPM) .......................................................................................37 Introduo .....................................................................................................................................37 Smbolos do Modelo de Processos do Negcio ...............................................................................37 Entidades Externas ........................................................................................................................37 Fluxos de Dados ............................................................................................................................39
II
FEA/USP - EAD-451 Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal Processos.......................................................................................................................................40 Arquivos de Dados.........................................................................................................................41 Construo do Modelo de Processos do Negcio ...........................................................................42 Lista de Verificao para o BPM ...................................................................................................43 Lista de Recomendaes para o BPM ............................................................................................44 MODELO RELACIONAL DE DADOS (RDM).............................................................................................46 Introduo .....................................................................................................................................46 Relacionamentos Um-para-Um ......................................................................................................48 Relacionamentos Um-para-Muitos.................................................................................................50 Relacionamentos Muitos-para-Muitos............................................................................................51 Conjuntos de Relacionamentos ......................................................................................................52 Variao no Tempo........................................................................................................................55 Tipos de Objeto..............................................................................................................................56 O Modelo Relacional de Dados (RDM - Relational Data Model) ...................................................57 Modelagem dos Dados...................................................................................................................58 Dados-chave ..................................................................................................................................64 Estruturas Embutidas.....................................................................................................................64 Mltiplas Chaves ...........................................................................................................................66 NORMALIZAO ..................................................................................................................................66 Introduo .....................................................................................................................................66 Primeira Forma Normal (1FN) ......................................................................................................67 Segunda Forma Normal (2FN) .......................................................................................................69 Terceira Forma Normal (3FN) .......................................................................................................71 Resultado da Normalizao de Arquivos........................................................................................72 RECONSTRUO DO BPM E DO RDM ...................................................................................................73 DESEMPENHO DO SISTEMA ...................................................................................................................74 Utilizao de ndices .....................................................................................................................74 Melhorando o Desempenho............................................................................................................75 DEFINIO DOS MDULOS DO SISTEMA ................................................................................................76 Introduo .....................................................................................................................................76 A rvore do Sistema ......................................................................................................................77 ESPECIFICAO DOS MDULOS DO SISTEMA .........................................................................................78 Introduo .....................................................................................................................................78 Implementao por Uma Pessoa ....................................................................................................78 Implementao por Vrias Pessoas ................................................................................................79 Dilogo Sistema x Usurio.............................................................................................................79 Exemplo de Especificao de Mdulo............................................................................................80 BIBLIOGRAFIA .....................................................................................................................................83
III
FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal
O Conceito de Sistema de Informao

Introduo Ao procurar um nmero de telefone, conferir seu saldo bancrio, escrever um relatrio, cuidar da velocidade do seu carro etc., voc est processando dados. O resultado de suas atividades em processamento de dados a informao, que voc usa para dirigir suas atividades. Quanto melhor informado voc estiver, mais facilmente alcanar seus objetivos. Ao menos trs grandes motivos combinados tornam o processamento de dados e a gerao de informaes to importante nas empresas: A complexidade crescente da sociedade moderna. A introduo da administrao cientfica. A tecnologia da informao. A globalizao da economia, a competio e o constante crescimento das empresas, ao mesmo tempo e na mesma proporo em que afasta os administradores de alto nvel da superviso mais direta das operaes, tende a tornar cada vez mais crtico o recurso informao e, consequentemente torna necessrio o processamento eletrnico dos dados. A Necessidade de Informao Imagine-se flutuando em um lugar completamente escuro e silencioso. No h odores, no existe a sensao de calor ou frio. O ar est parado, ou seja, voc no sente sensao alguma. Certamente voc se sentiria mal e no saberia exatamente o que fazer. O que est faltando ? Informao ! Voc precisa ver, ouvir, cheirar, sentir o seu lugar. Assim como o seu corpo depende de ar, gua e alimento para sobreviver, voc depende de informao. E no apenas para sobreviver, mas para alcanar seus objetivos: aprender, divertir-se, ajudar os outros, amar, se afirmar na sociedade e administrar empresas. A informao, portanto, possui importncia fundamental para todos ns, individual e coletivamente, isto , para as famlias, clubes, comrcio, escolas, indstrias, governo etc. A sobrevivncia e o sucesso das organizaes criadas pelo homem dependem fundamentalmente da informao. Sem ela estaro a esmo no escuro. O Conceito de Sistema Um sistema pode ser definido como "um conjunto de elementos quaisquer ligados entre si por cadeias de relaes de modo a constituir um todo organizado" (J.Maciel).
A palavra sistema envolve, de fato, amplo espectro de idias. Pode-se pensar em sistema solar, ou no corpo humano como um sistema. Diariamente deparamo-nos com sistemas de transporte, sistemas de comunicao, sistemas biolgicos, sistemas econmicos, sistemas de processamento de dados etc. Considera-se sistema um conjunto de elementos interdependentes, ou partes que interagem formando um todo unitrio e complexo que possui um objetivo. No entanto, preciso distinguir sistemas fechados, como as mquinas, um relgio etc., dos sistemas abertos, como os sociais e biolgicos: o homem, a sociedade, a empresa e a informao. Os sistemas abertos envolvem a idia de que determinadas entradas so introduzidas no sistema e que, aps processadas, geram certas sadas. Com efeito, a empresa vale-se de recursos materiais, humanos, tecnolgicos, financeiros e informaes, de cujo processamento resultam bens e/ou servios a serem fornecidos ao mercado.
Fig. 01 Sistema empresa
Cada um destes elementos, por sua vez tambm pode ser visto como um subsistema. Teremos, ento, uma hierarquia de sistemas e subsistemas (ou nveis).
Fig. 02 O subsistema de produo
As relaes entre os componentes podem representar as mais variadas interaes entre os elementos, tais como autoridade, comunicao, precedncia temporal, precedncia operacional, proximidade etc. As caractersticas inerentes a todos os sistemas so: Objetivo: Componentes: Estrutura: Comportamento: Ciclo Vital: a proposta fundamental de existncia de qualquer sistema. partes do sistema que funcionam juntas para alcanar os objetivos. a relao existente entre os componentes, definindo a fronteira entre o sistema e seu ambiente. a maneira do sistema reagir ao seu ambiente. nascimento, evoluo, desgaste, obsoletismo, envelhecimento, substituio, reparo e "morte" do sistema.
Uma grande contribuio da teoria de sistemas foi a de estudar as interaes do ambiente com a empresa e como adapt-la de modo eficiente s suas contingncias. O ambiente do sistema do exemplo anterior contm os seguintes elementos: clientes fornecedores de matria-prima mercado de mo-de-obra concorrentes fornecedores de recursos financeiros governo tecnologia etc. Obviamente, a empresa no pode ignorar as suas interaes com estes elementos. A Empresa como um Sistema As empresas, portanto, devem ser estudadas como sistemas abertos e, para efeito deste estudo, conveniente subdividir o sistema empresa em subsistemas, alguns dos quais podem ser apenas conceituais, isto , sem existncia fsica, mas apenas para uma melhor compreenso do fenmeno. Assim, podemos identificar nas empresas um subsistema denominado processo, cujas operaes resultam nos objetivos da empresa (produo de bens ou servios), um subsistema denominado administrativo, cuja funo assegurar o eficaz funcionamento do processo e um subsistema de informao, cuja funo captar, armazenar e fornecer as informaes necessrias para a empresa atingir eficazmente seus objetivos.
Ao considerarmos a empresa como um sistema, devemos nela identificar suas caractersticas bsicas, ou seja, objetivo, componentes, estrutura, comportamento e ciclo vital. Um objetivo tpico das empresas elevar o poder aquisitivo de seus proprietrios atravs de operaes lucrativas. Este um objetivo fundamental a longo prazo, e estratgico em sua natureza. Os objetivos de prazos mais curtos incluem os tticos, como aumento das vendas de um certo produto, reduo de horas extras de funcionrios e aperfeioamento da manuteno de equipamentos. Existem objetivos operacionais (rotineiros), tais como possuir o nmero adequado de funcionrios para atendimento de clientes, descobrir a causa do atraso na entrega de uma mercadoria, efetuar a venda de um produto, fabricar um produto, manter o controle de estoques atualizado etc. Os indivduos de uma empresa so geralmente agrupados em subsistemas, com atividades especializadas denominadas funes. Estes subsistemas so os componentes principais de uma empresa. Algumas das funes encontradas com maior freqncia incluem vendas, compras, finanas, contabilidade, produo, recursos humanos, processamento de dados ou informtica etc. A estrutura de uma empresa a maneira como autoridade e responsabilidades so distribudas entre os funcionrios e administradores de seus componentes. O comportamento das empresas determinado por seus procedimentos, que so seqncias especficas de atividades a serem desenvolvidas em conseqncia da poltica da empresa e da busca de seus objetivos. Os procedimentos orientam os funcionrios em como efetuar as tarefas que cada componente da empresa requer. Finalmente, o ciclo vital facilmente percebido atravs do aparecimento de novas empresas, sua evoluo e crescimento, suas mudanas, e atravs do desaparecimento de antigas e obsoletas empresas. Sistemas de Informao
Conceitos Bsicos
H muitas formas de se conceituar informao, dependendo do ngulo de observao e do campo de conhecimento em estudo. Do ponto de vista mais especfico de sistemas de informao pode-se examin-lo a partir do entendimento da informao como o resultado do tratamento de dados. Entende-se neste caso um dado como um item elementar de informao (um conjunto de idias ou fatos expressos atravs de letras, dgitos ou outros smbolos) que, tomado isoladamente, no transmite nenhum conhecimento, ou seja, no possui significado intrnseco. Partindo-se do conceito acima, pode-se definir informao como o resultado de fatos e idias relevantes, ou seja dados, que foram transformados (processados) numa forma 4
inteligvel para quem os recebe, e tem valor (utilidade) real ou aparente para a tomada de decises presentes ou futuras. Dentro desse conceito de informao, um sistema de informao um componente do sistema organizacional, constitudo por uma rede espalhada pela empresa inteira e utilizada por todos os seus componentes. Seu propsito obter informaes dentro e fora da empresa, torn-las disponveis para os outros componentes, quando necessitarem, e apresentar as informaes exigidas pelos que esto fora. Os sistemas de informao, em geral, so utilizados para orientar a tomada de deciso em trs nveis diferentes na administrao de uma empresa: o operacional, o ttico (ou gerencial) e o estratgico. O nvel operacional envolve decises pelas quais o administrador consegue que atividades especficas sejam executadas de modo eficaz e eficiente. J o nvel ttico envolve decises pelas quais o administrador assegura que os recursos so obtidos e usados de modo eficaz e eficiente para que os objetivos da empresa sejam atingidos. Finalmente, o nvel estratgico envolve as decises ligadas definio ou mudana dos objetivos da empresa, identificao dos recursos que devero ser usados para atingir estes objetivos e polticas para aquisio e uso destes recursos. As decises envolvidas nestes trs nveis tambm podem ser divididas em trs tipos, conforme a necessidade de uso de intuio e criatividade ou de raciocnio lgico: decises estruturadas, decises semi-estruturadas e decises no-estruturadas. As decises estruturadas so, em geral, repetitivas (rotineiras). O tomador de deciso tem, neste caso, paradigmas bastante precisos que lhe prescrevem quais as informaes necessrias e como utiliz-las no processo de deciso. Existem critrios objetivos para medir a qualidade da deciso tomada e os seus resultados. J as decises no-estruturadas so, em geral, nicas. O tomador de deciso est diante de um problema novo para o qual no h experincia anterior que lhe indique quais so as informaes relevantes, tampouco existe um consenso sobre um processo racional que deve ser seguido na tomada de deciso. difcil reconhecer uma deciso bem tomada. Por fim, as decises semi-estruturadas so as que possuem componentes estruturados e no-estruturados. Pela sua natureza e apoiando-se na prpria experincia, o tomador de decises procura transformar decises noestruturadas em estruturadas, j que deste modo se torna mais fcil decidir ou ento delegar o processo de tomada de deciso. Estas duas classificaes permitem uma caracterizao bastante til dos processos de deciso e dos sistemas de informao resultantes. Observa-se que as decises noestruturadas so mais freqentes nos altos escales da empresa, envolvidos com planejamento estratgico, ao passo que no nvel operacional predominam as decises estruturadas (por delegao dos nveis hierrquicos superiores). Este processo de tomada de deciso dos administradores cria fluxos de informao entre os diversos componentes da empresa. As informaes estratgicas, tticas e operacionais fluem em geral para cima e para baixo dos nveis de gerncia da empresa. Outras informaes e aes criam fluxos laterais de um componente operacional da empresa para 5
outro. E ainda outras informaes e aes criam fluxos entre as partes individuais dentro dos componentes da empresa. Qualquer sistema de informao empresarial, como o de contabilidade ou o de recursos humanos, possui o mesmo comportamento: captar e transportar os dados ao longo da estrutura da empresa (componentes da empresa) at o processamento e, a partir da, produzir informaes que desencadeiam outros fluxos de informao dentro da empresa. Portanto, um sistema de informao integra-se na empresa, em funo de sua estrutura, sua poltica, as pessoas e o tipo de deciso para a qual servir de base. Em vista disso, os sistemas de informao podem ser classificados em dois grandes grupos: Operacionais: Sistemas de Informao de Apoio s Operaes Gerenciais: Sistemas de Informao de Apoio Gesto
Sistemas de Informao Operacionais
No nvel operacional (do processo), os sistemas de informao so em geral condicionados pela tecnologia da empresa e pela organizao do seu processo produtivo. Os sistemas de apoio s operaes so tipicamente sistemas armazenadores de dados e processadores de transaes, ou seja, so redes de procedimentos rotineiros que servem para o registro e processamento das transaes correntes. Dentro desta categoria podemos identificar como sendo os mais tpicos o de contabilidade, o de folha de pagamento, o de controle de estoques, o de faturamento e o de contas a receber e a pagar. Os sistemas que se voltam para decises referentes s operaes envolvem o registro de muitos dados e a integrao e agregao de muitas transaes, tais como planejamento e controle da produo, custos e contabilidade.
Sistemas de Informao Gerenciais
Os sistemas de apoio gesto, ou sistemas de informaes gerenciais, no so orientados para o processamento de transaes rotineiras, mas existem especificamente para auxiliar processos decisrios. Por essa razo, tais sistemas devem ser flexveis e podem ter uma assistemtica freqncia de processamento. Incluem sistemas de previso de vendas, de anlises financeiras, oramentos e os sistemas voltados, de modo geral, ao planejamento e controle das operaes. Os sistemas de informao gerenciais, porm, so mais difceis de serem construdos e avaliados, porque suportam decises nos nveis superiores da hierarquia das empresas. O modo de tomar decises bastante varivel e a sua avaliao muito subjetiva, com forte dependncia do estilo do tomador de decises. Estes fatos indicam a necessidade de metodologias distintas para o desenvolvimento, seleo e implantao de sistemas de informao operacionais e gerenciais, pois os sistemas de informao devem ser estudados luz dos processos transacionais ou decisrios aos quais devem servir. Das peculiaridades destes processos pode-se, ento, derivar suas caractersticas mais adequadas. 6
Requisitos de um Sistema de Informao
Um sistema de informaes eficaz deve satisfazer os seguintes requisitos bsicos: Produzir as informaes realmente necessrias, confiveis, em tempo hbil e com custo condizente, atendendo aos requisitos operacionais e gerenciais de tomada de decises a que tais informaes devem suprir. Ter por base diretrizes capazes de assegurar o atendimento dos objetivos da organizao, de maneira direta, simples e eficiente. Integrar-se estrutura da organizao e auxiliar na coordenao entre as diferentes unidades organizacionais (departamentos, divises, e diretorias) por ele interligadas. Ter um fluxo de procedimentos (internos e externos ao processamento) racional, integrado, rpido e de menor custo possvel. Contar com dispositivos de controle interno que garantam a confiabilidade das informaes de sada e adequada proteo aos dados controlados pelo sistema. Ser fcil, simples, seguro e rpido em sua utilizao. O computador, pela sua capacidade de armazenar considervel volume de dados e de process-los a grandes velocidades, pelos recursos que oferece para aumentar a confiabilidade da informao e pelas possibilidades que introduz de reteno, recuperao, pesquisa e transmisso de informaes e comunicao entre pessoas, uma ferramenta adequada para a implementao de sistemas de informao de alta qualidade. Porm, a simples introduo de recursos de informtica nos sistemas de informao de uma empresa, no representa uma garantia de soluo de seus problemas. Por si s, o computador no assegura que a empresa passe a contar com sistemas de alta qualidade. Ao mesmo tempo, porm, sem o seu emprego, certas necessidades e benefcios objetivados no planejamento dos sistemas de informao empresariais podem no ser factveis, e at mesmo pode no ser possvel encontrar solues viveis para determinados problemas. O constante crescimento das empresas, ao mesmo tempo e na mesma proporo em que afasta seus dirigentes da superviso mais direta das operaes, tende a tornar cada vez mais crtico o recurso da informao e, consequentemente, necessrio o processamento eletrnico de dados, ou seja, a utilizao da tecnologia da informao. No contexto atual, imprescindvel que as empresas automatizem seus sistemas de informao, com o risco de se no o fizerem tornarem-se menos competitivas, menos geis e at mesmo no sobreviverem. Nesse sentido, como veremos a seguir, o primeiro passo para iniciar-se um processo de informatizao a identificao das necessidades de informao e das aplicaes a serem informatizadas.
Componentes de um Sistema de Informao Automatizado Em um sistema de informao automatizado, isto , que utiliza os recursos da tecnologia de informao, existem quatro componentes essenciais: hardware, software, dados e usurios. Estes, por sua vez, esto inseridos num contexto mais amplo, de aplicao numa empresa, com o objetivo de produzir determinados bens ou servios.
q
Hardware: composto pelos equipamentos de informtica utilizados pelo sistema, como computadores, impressoras, leitores ticos, mouse etc., e pelos recursos de comunicao que os conectam entre si, como modems, linhas, cabos, concentradores, roteadores etc. Software: composto pelos sistemas operacionais e diversos programas de computador que fornecem instrues especficas sobre as tarefas que o hardware deve executar para gerar a informao desejada. Dados: so compostos por fatos e idias relevantes que registrados e processados de forma adequada permitem gerar a informao desejada. Usurios: so compostos pelas pessoas que realizam as tarefas necessrias para o adequado funcionamento dos demais componentes do sistema de informao e pelas pessoas que solicitam e utilizam as informaes por ele geradas.
Necessidades de Informao
Tipos de Informao Para a definio dos sistemas de informao a serem automatizados numa empresa, interessante classificar-se as informaes necessrias em externas e internas. As informaes externas so aquelas que a empresa troca com o seu meio ambiente (outras empresas, clientes e governo) e as internas so aquelas trocadas entre suas diversas reas e nveis de deciso (contabilidade, pessoal, produo e diretoria). Informaes Externas Qualquer empresa est inserida num ambiente e, por isso, tem necessidade de se comunicar com este ambiente. Tipicamente pode-se considerar que o ambiente de uma empresa formado por fornecedores, clientes, instituies financeiras, acionistas, concorrentes, governo e o pblico em geral.
q
Fornecedores: todas as empresas se relacionam com fornecedores, com quem negociam para a aquisio de produtos (matrias-primas) e servios, ou seja, insumos necessrios ao desenvolvimento de seus negcios. Algumas informaes bsicas a respeito dos fornecedores seriam: nome, endereo, telefones, produtos/servios ofertados, prazos de entrega, preos e condies de pagamento. 8

q
Clientes: so fundamentais a qualquer empresa. So os clientes que geram resultados para a empresa, sem clientes no h empresa. Algumas informaes bsicas a respeito dos clientes seriam: nome, endereo, telefones, produtos/servios e respectivas quantidades adquiridos, pagamentos efetuados/a efetuar, pagamentos em atraso, pedidos efetuados/pendentes, nome do comprador e nome do vendedor. Instituies Financeiras: para qualquer atividade empresarial so necessrios servios bancrios. Alm do aspecto de prestao de servios (conta corrente, cobranas e recebimentos), as instituies financeiras tm o papel de financiar negcios (descontos de duplicatas e emprstimos) e de realizar investimentos (aplicaes financeiras). Concorrentes: so as empresas que atuam no mesmo ramo de atividade, disputando o mesmo mercado. A empresa precisa obter informaes sobre seus concorrentes, pois somente assim poder se situar no mercado (volume de vendas e tipos de produtos), verificar os lanamentos de novos produtos ou servios, os pontos de venda que esto sendo atingidos, a poltica de preos est sendo praticada e a tecnologia que est sendo utilizada. Quanto aos concorrentes, preciso ter informaes como quem so, onde esto localizados, quais os produtos que esto vendendo mais, quanto esto faturando e que estratgias competitivas esto praticando. Scios/Acionistas: so as pessoas que investiram seu capital na empresa, e esperam um retorno compensatrio. Mesmo sendo de capital fechado, como o caso da maioria das pequenas e mdias empresas, podero haver vrios acionistas ou scios que devero ser periodicamente informados sobre a situao da empresa e sobre a diviso dos lucros. Governo: o governo um elemento muito importante, principalmente pelo controle que exerce sobre a atividade das empresas. Assim, necessrio fornecer-lhe uma srie de informaes fiscais e sociais que dependem do setor de atuao da empresa, entre elas: Imposto de Renda (empresa e funcionrios), Descontos para a Previdncia Social (empresa e funcionrios), FGTS (empresa e funcionrios), impostos (ICMS, ISS, IPI, PIS e FINSOCIAL) e RAIS. Pblico em Geral: apesar de no ter um relacionamento direto com o pblico, cada vez mais, devido a movimentos ecolgicos, controle de poluio e urbanizao e cdigo do consumidor, as empresas so solicitadas a fornecer informaes sobre suas atividades, produtos e servios, principalmente aquelas que atuam em setores sensveis a estes problemas.
Informaes Internas Qualquer empresa, na medida em que se desenvolve, dividida em reas funcionais ou departamentos, para que consiga executar suas atividades de forma mais eficiente. Alm disso, h uma hierarquia de decises na empresa, que vai dos nveis operacionais (inferiores) aos gerenciais e estratgicos (superiores). O conceito de nveis de hierarquias,
nos quais o superior determina as aes dos inferiores, no se limita coordenao de pessoas, mas estende-se s demais funes da empresa e at para outros tipos de sistemas. Para as decises operacionais so necessrias informaes sobre as rotinas e tarefas que se referem operao da empresa, como volumes de estoques, produo, vendas e pagamento de funcionrios. Para as decises gerenciais so necessrias informaes que permitam o planejamento e o controle das operaes da empresa, como estatsticas de vendas, rotatividade dos estoques e anlises financeiras. Finalmente, para as decises estratgicas so necessrias informaes relacionadas alta direo da empresa, como oportunidades de investimento e novas tecnologias. O conceito de nvel decisrio importante, pois as tarefas em cada nvel, operacional, gerencial e estratgico, so diferentes, e consequentemente as necessidades de informao so diferentes. Contudo, estes nveis no so estanques. Ao contrrio, interagem entre si, gerando um fluxo de informaes dos nveis inferiores para os superiores e vice-versa. As reas funcionais desempenham tarefas especficas ligadas cada uma das funes necessrias atividade global da empresa. Para tanto, so necessrias informaes operacionais, gerenciais e estratgicas, que geram um fluxo de informaes dentro de cada rea e entre elas, pois a atividade global a integrao da atividade de cada funo e umas dependem das outras. A seguir, apresentamos uma lista de funes e atividades, tanto a nvel operacional como gerencial, que inclui a maioria dos sistemas de informao de uma tpica empresa industrial:
01. Administrao Financeira e Contbil 01.1 Contabilidade Geral 01.2 Contabilidade Fiscal 01.3 Contas a Pagar 01.4 Contas a Receber 01.5 Tesouraria 01.6 Controle de importaes 01.7 Controle de exportaes 01.8 Custos 01.9 Oramentos 02. Administrao de Recursos Humanos 02.1 Folha de pagamentos 02.2 Controle de Frias 02.3 Controle de ponto 02.4 Controle financeiro de pessoal 02.5 Assistncia mdica
10
FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal 02.6 Administrao de salrios 02.7 Administrao de cargos/funes 02.8 Desenvolvimento/treinamento 02.9 Higiene e segurana do trabalho 02.10 Apoio assistncia social 03. Administrao Comercial 03.1 Cotaes de preos para clientes 03.2 Administrao da carteira de pedidos 03.3 Faturamento 03.4 Estatsticas de vendas 03.5 Expedio 03.6 Clculo de comisses de vendas 03.7 Administrao de transportes 03.8 Informaes para clientes 03.9 Assistncia tcnica 04. Administrao da Rede Logstica 04.1 Administrao interna de vendas 04.2 Administrao de filiais 05. Administrao de Marketing 05.1 Anlises de mercados 05.2 Administrao de preos 05.3 Apoio propaganda 05.4 Planejamento de vendas 06. Planejamento Financeiro 06.1 Projeo do fluxo de caixa 06.2 Anlises econmico/financeiras 06.3 Anlises de investimentos 06.4 Anlises de financiamentos 07. Administrao Geral 07.1 Follow-up administrativo 07.2 Controle de projetos 07.3 Controle de contratos 07.4 Controle de seguros 07.5 Controle de veculos
11
FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal 08. Administrao de Compras e Materiais 08.1 Compras nacionais 08.2 Importaes 08.3 Recebimento de materiais 08.4 Controle de estoques de matrias-primas 08.5 Controle de obsolescncias 08.6 Controle de materiais indiretos 08.7 Controle de estoques materiais de escritrio 08.8 Cadastro de fornecedores 09. Pesquisa e Desenvolvimento 09.1 Apoio pesquisa de produtos 09.2 Apoio ao desenvolvimento de produtos 09.3 Cadastro de informaes tcnicas 10. Administrao da Produo 10.1 Planejamento da produo 10.2 Programao da produo 10.3 Carga de mquinas 10.4 Controle da produo 10.5 Fechamento de ordens de produo 10.6 Controle de produtividade 10.7 Controle de processos 10.8 Controle de servios externos 10.9 Estatsticas de produo 11. Controle de Qualidade 11.1 Especificaes de padres 11.2 Verificao de qualidade 11.3 Estatsticas de qualidade 12. Manuteno e Ferramentaria 12.1 Planejamento de manuteno preventiva 12.2 Controle de manuteno 12.3 Estatsticas de paradas 12.4 Controles de moldes e dispositivos 12.5 Controle de ferramental 12.6 Metrologia e instrumentos
12
FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal 13. Outros Sistemas Industriais 13.1 Apoio a tempos e mtodos 13.2 Projeto de produtos 13.3 Projeto de moldes e ferramentas
Na prtica as necessidades de informaes externas e internas esto integradas. Por exemplo, faturamento deve tambm fazer o controle do ICMS, assim como a folha de pagamento deve fazer o controle de descontos de Imposto de Renda, Previdencirio e FGTS. Portanto, as necessidades de informaes globais da empresa combinam informaes externas e internas, e estas devem ser atendidas pelos sistemas de informao. Supondo que uma empresa planeja adquirir um sistema de computao para dele obter o maior benefcio possvel, a metodologia que apresenta-se a seguir procura identificar, atravs de cinco etapas, as necessidades de informao e as correspondentes aplicaes cuja informatizao traro maior impacto nos negcios da empresa, atravs da melhoria de seus sistemas de informao.
Metodologia para Identificao das Necessidades de Informao

Etapa 1 Identificao dos Objetivos e dos Fatores Crticos de Sucesso
A meta desta etapa definir claramente os objetivos da empresa e os problemas existentes para alcanar tais objetivos. Se deve considerar, entretanto, os problemas que podem ou devem ser resolvidos de outra forma que no atravs da informtica. Se h problemas para a manipulao do volume de dados e papis com o pessoal existente, se a informao que importante para o funcionamento do negcio no est disponvel, razovel presumir que melhores informaes conduziro a uma maior eficcia no controle de estoques, na cobrana dos devedores ou em algum aspecto da produo. A informatizao desses processos atravs de um computador pode, ento, ser justificada. Um dos mais relevantes aspectos a serem analisados no posicionamento estratgico de qualquer empresa, refere-se aos fatores fundamentais para o sucesso no seu ramo de atividade. Um nmero muito grande de fatores influi no desempenho de uma empresa. Por exemplo, ter a contabilidade mensal encerrada dentro dos limites de prazos estabelecidos, e com exatido nas informaes, uma das principais preocupaes dessa rea funcional da empresa; da mesma forma, ter a folha de pagamento pronta e correta alguns dias antes da data de pagamento dos funcionrios um a das principais preocupaes da rea de pessoal. Entretanto, apenas alguns fatores respondem pela quase totalidade das possibilidades de sucesso de qualquer negcio. Esses fatores so bsicos para o bom desempenho da empresa e, por isso, so denominados fatores crticos de sucesso ou fatores chave de sucesso. Por mais que uma empresa possa ser eficiente nas suas diversas 13
reas operacionais, se ela estiver vulnervel em fatores crticos de sucesso, muito provvel que no consiga ter a competitividade necessria para garantir sua sobrevivncia. Para uma loja comercial, podem ser considerados os seguintes fatores crticos de sucesso: Localizao. Variedade de produtos e marcas. Preos e crdito para os clientes. Conforto do cliente para realizar suas compras. As seguintes caractersticas fundamentais so tpicas para os fatores crticos de sucesso (FCS) de uma empresa: So poucos. Tm importncia vital para a organizao. So diferenciadores entre organizaes. Tm grande influncia sobre as relaes da empresa com o ambiente, principalmente com os mercados atingidos ou pretendidos. So caractersticas do ramo ou categoria de produtos. Podem estar distribudos pelas diversas atividades operacionais da empresa, principalmente por aquelas que representam as partes mais significativas de seus processos operacionais. Muitos dos FCS so relacionados s caractersticas da categoria de produtos em face das necessidades bsicas dos consumidores ou clientes e s utilidades por eles percebidas. Os principais pontos de pesquisa para encontrar e identificar os fatores crticos de sucesso so: Necessidades bsicas para atender as utilidades fundamentais percebidas pelos consumidores ou clientes. Relaes da empresa com o mercado. Processos, tecnologias e custos. Anlise dos insumos vitais. Capacidade de produo. Capacidade financeira. Porte e estrutura organizacional. Relacionamento empresa x ambiente. Como primeiro passo, a empresa deve, portanto, identificar claramente os seus objetivos, os fatores crticos de sucesso para alcan-los e os problemas existentes nos procedimentos atuais. 14
Etapa 2
Levantamento das reas de Aplicao da Informtica
Identificados os objetivos, os fatores crticos de sucesso e os problemas atuais da empresa, a prxima etapa empreender uma busca das possveis reas de aplicao da tecnologia da informao, questionando como esta poderia ser utilizada na automatizao de sistemas de informao, para tornar a empresa mais competitiva e eficiente. Complementarmente, pode-se questionar cada uma das principais reas funcionais da empresa, no sentido de serem identificadas suas contribuies especficas para cada um dos fatores crticos de sucesso apontados e, ento, identificar outras possveis aplicaes da informtica que dem apoio a essas contribuies. Dessa forma, tem-se uma anlise profunda das possibilidades de uso da informtica orientada para os objetivos da empresa atravs de seus fatores crticos de sucesso. Esta etapa consiste, portanto, em realizar levantamentos junto a cada uma das reas funcionais da empresa, bem como identificar, a partir dos prprios ocupantes dessas funes, os usos atuais e potenciais (ou aplicaes) da informtica que possam servir de apoio a elas. Esses levantamentos devem avaliar: Contribuies de cada funo para com os objetivos bsicos e estratgicos da empresa. Contribuies de cada funo para com os fatores crticos de sucesso apontados. Identificao dos fatores crticos de sucesso para cada funo. Processos e decises inerentes s funes. Tipos de atividades relacionadas organizao do trabalho. Informaes utilizadas e geradas por cada funo. Alm da identificao e anlise de cada um dos aspectos citados, ao nvel de cada funo, tambm devero ser questionados, do ponto de vista do usurio e dos usos potenciais da informtica, as necessidades individuais existentes, seja em termos de novas aplicaes ou em modificaes daquelas j implantadas. Esta etapa do processo uma das mais trabalhosas porque implica na execuo de levantamentos junto s diversas reas, departamentos, chefias ou funes da empresa, de forma a serem identificadas, claramente, as principais necessidades de informao e, consequentemente, possveis aplicaes da informtica. Recomenda-se que a relao das reas de aplicao seja ampla, no implicando, contudo, que os passos posteriores devam abordar todas as reas em detalhe. A menos que se listem todas as reas de aplicao possveis, pode-se omitir a viso futura de crescimento da empresa e tomar decises que no levem em considerao reas que sero importantes. Aps tomarem-se decises a respeito das provveis reas de aplicao, deve ser elaborada uma lista de necessidades. Esta lista no deve ser um documento tcnico, mas simplesmente uma descrio da empresa e de suas principais necessidades de informao. Uma lista de necessidades deve constar de: 15
Uma descrio breve da empresa, indicando suas atividades, o nmero de funcionrios, sua localizao e filiais (se for o caso) e os processos pouco usuais referentes sua forma de operar. Uma lista das aplicaes automatizadas ou a serem automatizadas. Descrio relativa a cada aplicao, incluindo os dados necessrios e as informaes desejadas. Obtidas as reas de aplicao da informtica, ou apenas aplicaes, e as necessidades de informao, pode-se passar para a etapa seguinte. Etapa 3 Consolidao das Aplicaes Identificadas
Visando a obteno de uma relao geral das necessidades de informao e dos sistemas de informao a serem automatizados, deve ser realizada uma sumarizao e agrupamento de todas as proposies obtidas na etapa anterior, de forma que se apresentem organizadas por fator crtico de sucesso e rea de aplicao. No levantamento funcional da etapa anterior so, em geral, identificados problemas e necessidades de informao que extrapolam a funo analisada, interagindo com outras, sendo, portanto, fundamental que um trabalho de classificao, organizao e consolidao das aplicaes seja conduzido. Por outro lado, cada rea funcional da empresa responsvel por processos, que podem ser definidos como um grupo de decises e atividades logicamente relacionadas, necessrias para administrar os recursos e operaes sob sua responsabilidade. A disponibilidade de informaes um dos pr-requisitos bsicos para a execuo dos processos. Tais necessidades de informaes so supridas com informaes geradas por outros processos. O que se tem, portanto, uma grande interdependncia entre os vrios processos, sendo essa interdependncia maior para processos de um mesmo grupo. O resultado desta etapa deve ser, portanto, uma relao de aplicaes da tecnologia da informao, consolidada e integrada, resultante da anlise das funes e processos a que daro apoio e das necessidades de informao (dados a serem processados e informaes a serem geradas) da empresa como um todo. Com base nesse resultado, indispensvel identificar, de forma precisa, quais so as informaes necessrias execuo de cada processo. A funo primordial do sistema de informao ser fornecer essas informaes (na quantidade certa, no prazo oportuno, a um custo razovel e na exatido requerida) aos participantes da execuo de cada processo. necessrio, portanto, identificar e classificar os dados criados, controlados e utilizados pelos processos, podendo para isso ser utilizado o conceito de classe de dados. Etapa 4 Definio das Classes de Dados
Uma classe de dados uma categoria de dados logicamente relacionados que so necessrios para dar apoio aos negcios da empresa. Estes dados devem ser identificados e classificados com o objetivo de determinar: 16
Exatido, oportunidade e disponibilidade dos dados que so normalmente utilizados nos processos. Classes de dados utilizadas nos sistemas de informaes existentes ou a implantar. Dados atuais e potenciais compartilhados pelos processos. Dados criados, controlados e utilizados por cada processo. Informaes que so necessrias mas que no esto disponveis. Quais so, tendo em vista os fatores crticos de sucesso, os sistemas de informao mais necessrios ou que precisam ser melhorados. As classes de dados so mais facilmente identificadas se divididas nos quatro tipos, relacionados a seguir.
Dados Cadastrais
So dados referentes ao registro de entidades e recursos ligados atividade da empresa. Por exemplo, dados sobre: clientes, fornecedores e funcionrios, produtos.
Dados Transacionais
So os dados referentes a todas as transaes efetuadas pela empresa. Por exemplo, dados sobre: compras, vendas, ordens de produo, pagamento a funcionrios, contas a pagar e contas a receber.
Dados de Controle
So extrados dos dados cadastrais e transacionais para permitir anlises sobre o desempenho da empresa. Geram medidas de controle dos negcios; por exemplo, volumes de vendas por produto, vendedor ou cliente.
Dados de Planejamento
Representam os objetivos ou nveis esperados dos dados cadastrais e do volume de transaes. So obtidos e estudados a partir dos trs tipos anteriores; por exemplo, previso de vendas por produto, vendedor ou cliente. Dados Cadastrais e Transacionais em uma Empresa Industrial
DADOS CADASTRAIS 01. Contas contbeis 02. Bancos 03. Centros de custos 04. Funcionrios 05. Clientes DADOS TRANSACIONAIS 01. Lanamentos contbeis 02. Custos 03. Notas Fiscais/Faturas 04. Duplicatas a receber 05. Processos de exportaes
17
FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal DADOS CADASTRAIS 06. Vendedores 07. Filiais e escritrios 08. Representantes 09. Produtos e acessrios 10. Classes de produtos 11. Veculos 12. Mquinas e equipamentos 13. Matrias-primas 14. Produtos Semi-acabados 15. Materiais indiretos 16. Fornecedores 17. Centros de produo 18. Padres de produo 19. Processos de produo 20. Projetos e Desenhos 21. Especificaes e moldes 22. Ferramentas 23. Transportadoras 24. Concorrentes DADOS TRANSACIONAIS 06. Consultas de clientes 07. Pedidos de clientes 08. Pedidos a fornecedores 09. Processos de importaes 10. Notas Fiscais de compras 11. Ttulos a pagar 12. Lanamentos bancrios 13. Requisies de mat.primas 14. Ordens de produo 15. Registros de produo 16. Ordens de manuteno 17. Requisies de ferramenta 18. Requisies instrumentos 19. Requisies de moldes 20. Alteraes de projeto 21. Assistncia tcnica 22. Manutenes Preventivas 23. Ordens de embarque
18
As necessidades de informao, ou seja, dados a serem processados e informaes a serem geradas, referentes s aplicaes obtidas na etapa anterior, devem nesta etapa ser consolidadas e classificadas, de acordo com os processos a que daro apoio e com a classe de dados de que fazem parte. Nesta etapa tambm devem ser estimados os principais volumes de dados cadastrais e transacionais processados na empresa diariamente, semanalmente ou mensalmente, e seus incrementos futuros. Essa estimativa servir como uma das bases para o dimensionamento do sistema de computao (hardware, software e usurios) necessrio para a informatizao da empresa. As rotinas e sistemas transacionais so relativamente comuns entre as empresas, o mesmo acontecendo com os dados cadastrais e transaes principais. Desta forma, pode-se utilizar uma tabela de referncia para consulta quanto aos volumes a serem levantados. Etapa 5 Priorizao das Aplicaes a serem Informatizadas
H basicamente dois caminhos que podem ser seguidos na determinao de aplicaes que devem ser prioritariamente informatizadas. Em alguns negcios certas atividades tomam muito mais tempo que outras e causam a maioria dos problemas e erros. Outras atividades dirias so fceis de serem executadas e esto sujeitas a poucos erros. As opes so portanto duas: podem ser informatizadas inicialmente as reas administrativas mais difceis do negcio ou podem ser informatizadas as atividades mais simples. Adotando a primeira opo, ser possvel obter resultados rapidamente no sentido de reduo de tempo, problemas e erros na execuo das atividades. Por outro lado, adotando a segunda opo, haver menos chance de fracasso e, informatizando as atividades mais simples primeiro, a empresa ter mais facilidade para informatizar posteriormente as atividades mais complexas. A opo ideal, contudo, talvez seja iniciar a informatizao da empresa por aplicaes que constituam um meio-termo, ou seja, nem to complexas nem to simples. Tendo-se a lista de aplicaes a serem informatizadas, cada uma delas dever, ento, passar por um processo de priorizao atravs de uma anlise de custos e benefcios especficos, em que devero ser levadas em considerao vrias dimenses de importncia. As seguintes dimenses de importncia podem ser consideradas na avaliao das aplicaes:
19
Importncia Estratgica
Relacionada aos impactos que a aplicao proposta traria competitividade e proteo da empresa, principalmente face a concorrentes, mercados e fornecedores. Os principais critrios a serem considerados nesta dimenso so: aumento da competitividade da empresa, reduo da dependncia em relao a terceiros, aumento da dependncia de clientes em relao empresa, melhor qualidade de produtos e servios, melhoria da imagem institucional, aumento da agilidade e flexibilidade operacional.
Importncia Funcional
Relacionada melhoria que a aplicao ou sistema proposto traria sobre a eficincia e performance no trabalho da rea afetada, inclusive ao nvel de desempenho de gerentes e profissionais administrativos. Os principais critrios a serem considerados nesta dimenso so: melhores informaes funcionais, melhor performance de pessoal, melhores comunicaes e base de integrao para outras aplicaes.
Importncia Organizacional
Relacionada melhoria que a aplicao ou sistema proposto trar para a organizao como um todo, em aspectos como comunicaes, capacitao, integrao, agilizao de decises e segurana. Os principais critrios a serem considerados nesta dimenso so: melhores comunicaes, demandas impostas pela necessidade de segurana de dados, melhor controle e funcionamento da empresa, menor nmero de problemas operacionais e gerenciais, base para capacitao futura (aquisio de experincia), base para acompanhamento tecnolgico e base para estmulo capacitao e aperfeioamento profissional.
Importncia Devida a Demandas Externas
Relacionada ao fato de a aplicao ou sistema proposto se justificar por existir uma imposio externa empresa, obrigando-a a manter informaes de interesse de agentes externos (governos), como o caso da escriturao fiscal, de informaes aos acionistas e informaes ao pblico em geral. Os principais critrios a serem considerados nesta dimenso so: obrigatoriedade de fornecimento de informaes aos agentes externos, periodicidade, nvel de exigncia e divulgao institucional.
Importncia Econmica
Decorrente, principalmente, de economias de custos ou ganhos financeiros, como o caso da reduo nos prazos de recebimentos de vendas, com a implantao de um sistema de contas a receber; reduo do prazo de entrega de mercadorias, com a implantao de um sistema de controle da produo. Os principais critrios a serem considerados nesta dimenso so: redues de custos, aumento da produtividade e eficincia, ganhos de tempo, ganhos econmicos em termos de fluxo de caixa e aumento do nvel de atividade. 20
Atravs destas dimenses gerais, praticamente todos os possveis fatores relevantes na avaliao do interesse em automatizar determinada funo, processo ou sistema de informao estaro sendo considerados. tambm uma avaliao muito mais abrangente e subjetiva que os processos tradicionais em que praticamente s a dimenso econmica considerada. Por esse motivo, importante que os dirigentes da empresa participem e mantenham controle sobre o processo de informatizao. Esta responsabilidade no deve ser delegada a um consultor externo ou a um funcionrio, e muito menos a um fornecedor. Resultado da Metodologia O resultado final da metodologia descrita pode ser apresentado em um quadro, onde so relacionadas todas as necessidades de informao, as respectivas aplicaes que as fornecero, as reas funcionais envolvidas, os dados cadastrais e transacionais necessrios e os respectivos volumes. A partir desse quadro, pode ser definido um fator de prioridade para os sistemas de informao a serem implantados. Para a obteno do fator de prioridade sugere-se que cada aplicao ou sistema proposto seja avaliado segundo as cinco dimenses de importncia citadas, atribuindo-se notas variando de B (baixa, nota 1), M (mdia, nota 5), a A (alta, nota 10). Estabelecendo-se pesos para cada uma das dimenses apontadas (sugerindo-se 10 para a estratgica, 5 para a funcional e organizacional, 1 para a externa e 9 para a econmica), todas as aplicaes ou sistemas devem ter suas notas ponderadas, obtendo-se um total de pontos correspondente ao fator de prioridade. Dessa forma, as aplicaes ou sistemas de informao com maior nmero de pontos devem ser consideradas como mais importantes e prioritrios.
21
Informao Clientes
Aplicao Faturamento Contas a Receber
rea Vendas Financeiro
Dados Cadastrais Nome do cliente CGC/CPF Endereo Telefone Fax Crdito etc. Nome do Cliente CGC/CPF Inscrio Endereo Vendedor
Dados Transacionais
Vendas
Faturamento
Vendas Financeiro Contabilidade
N da Nota Fiscal Data da Emisso Valor Comisso Venda Impostos Produto/Servio Quantidade Preo Unitrio Desconto etc.
Fornecedores
Estoque
Compras Almoxarifado Contas a Pagar
Nome CGC/CPF Endereo Telefone Fax. Cidade Estado CEP etc. Etc. Etc.
Etc.
Etc.
Etc.
22
Definio dos Requisitos de um Sistema de Informao

Introduo O projeto detalhado de um sistema de informao a ser desenvolvido somente deve ocorrer aps a definio das necessidades de informao da organizao ou do usurio que ir utiliz-lo. Tradicionalmente, para a obteno das definies necessrias para o desenvolvimento de um sistema de informao automatizado, o desenvolvedor deve entrevistar cada usurio da informao, ou gerente da organizao, envolvidos nas reas que sero afetadas pelo sistema. Aps este trabalho, que poder demandar considervel tempo, as anotaes coletadas devem ser resumidas num documento de definio de requisitos ou de especificao do sistema a ser desenvolvido. Relao de Requisitos do Sistema Um documento com a definio dos requisitos de um sistema de informao deve constar basicamente de: Dados a serem processados Informaes a serem geradas Recursos especiais
Dados a Serem Processados
Devem ser relacionados os dados a serem captados, armazenados e processados pelo sistema. Assim, por exemplo, para o faturamento, o cadastro dos clientes dever conter o cdigo do cliente, o nome, o endereo, o limite de crdito, a regio de venda, condies de comercializao, o vendedor responsvel e o saldo atual do cliente. Como comprovao, deve-se analisar os documentos do sistema de informao atual (manual ou no), para verificar se todos os dados necessrios foram includos. Tambm interessante anotar-se o nmero de posies necessrio para cada dado, por exemplo, o nome do cliente pode ter at 40 letras ou posies e as regras necessrias para verificar a validade de cada dado, por exemplo, o sexo do funcionrio s deve aceitar as letras M ou F.
Informaes a Serem Geradas (consultas e relatrios)
Deve-se relacionar as consultas desejadas na tela do computador e os relatrios impressos a serem fornecidos pelo sistema para satisfazer as necessidades de informao dos usurios, informando sua freqncia, (diria, semanal, mensal ou anual), seu contedo, ordem de emisso e clculos necessrios para a obteno das informaes.
23
Recursos Especiais
Deve-se obter com a mxima preciso possvel uma descrio das regras, clculos ou processamentos especiais que o sistema deve seguir para gerar as informaes necessrias, as facilidades e recursos que deve oferecer e as excees regra geral que podero ocorrer. Todos os cdigos que sero utilizados para classificar clientes, produtos, funcionrios, processos, contas contbeis e transaes tambm devem ser descritos com detalhes. Grupo para Especificao do Sistema Como forma de reduzir o tempo gasto no levantamento das informaes necessrias para definir os requisitos do sistema, os representantes dos usurios mais relevantes podero ser reunidos em um grupo, juntamente com a equipe de desenvolvimento, numa sesso de trabalho contnua, que poder durar de um a trs dias, para especificar as caractersticas e funes do sistema. Quando bem conduzidas por algum com grande interesse no sucesso do sistema, essas reunies de trabalho vo alm da mera funo de coleta de informaes. Os usurios acabam envolvidos com o processo de desenvolvimento do sistema, tomam decises a respeito da sua abrangncia e caractersticas e saem com o positivo sentimento de que o sistema ser feito por eles prprios, e que o "desenvolvedor" est apenas ajudando.
Bases de Dados
Introduo Uma base de dados (ou banco de dados) pode ser definida como um conjunto unificado de informao que vai ser compartilhado pelas pessoas autorizadas de uma organizao. A funo bsica de uma base de dados permitir o armazenamento e a recuperao da informao necessria para as pessoas da organizao tomarem decises, eliminando redundncias. Quando coexistem vrias cpias de uma mesma informao, comum ocorrer discrepncias entre elas, podendo-se chegar ao extremo de se tornar impossvel determinar qual das diferentes verses a correta. Em uma base de dados corretamente projetada no deve existir informao redundante e, portanto, a possibilidade de que se produzam inconsistncias entre os dados minimizada. Normalmente, nos microcomputadores, as informaes necessrias uma organizao se distribui em um conjunto de bases de dados. Cada uma das bases de dados contm informaes sobre uma determinada rea ou funo da organizao. Uma delas pode ter sido desenvolvida para armazenar informaes da rea financeira, outra da rea de pessoal e uma terceira da rea de vendas ou produo.
24
Por outro lado, em computadores de maior porte, as informaes necessrias uma organizao so armazenadas numa nica base de dados corporativa, que contm informaes sobre todas as reas e funes da organizao de forma integrada, consistente e consolidada. Todos os sistemas de informao da organizao compartilham esta nica base de dados. Independentemente da base de dados que ser implantada, a funo de um Sistema de Gerenciamento de Base de Dados (SGBD) a mesma. O SGBD pode ser definido como sendo o conjunto de hardware e software que possibilitar aos usurios o acesso e a utilizao eficiente da base de dados. O SGBD deve se encarregar da comunicao entre o usurio e a base de dados, proporcionando a este meios de pesquisar e obter informaes, introduzir novas informaes e atualizar as existentes. Estrutura de uma Base de Dados Uma base de dados formada por um conjunto de arquivos de dados, tambm chamados de tabelas, que contm a informao nela armazenada. O conjunto de tabelas ou arquivos ilustrados a seguir pode ser considerado como pertencente uma base de dados de compras. ARQUIVO DE PRODUTOS
Cdigo 1.01.001 1.01.002 1.02.001 2.01.001 3.01.001 4.01.001 4.01.002 4.02.001 4.02.002 4.02.003 . . Nome CD-ROM Regravvel 5 1/4" Disco Flexvel de 5 1/4" 1,2 Mbytes Disco Flexvel de 3 1/2" 1,44 Mbytes Cartucho de Tinta para Impressora Papel carta para impressora. Microcomputador Pentium 200 Mhz Microcomputador Pentium 233 Mhz Microcomputador Pentium II 266 Mhz Microcomputador Pentium II 300 Mhz Microcomputador Notebook 233 Mhz . . Unidade Unidade Caixa com 10 Caixa com 10 Unidade Pacote com 1000 folhas Unidade Unidade Unidade Unidade Unidade . .
25
ARQUIVO DE FORNECEDORES
Cdigo 0001 0002 0003 . . Nome Arapuca Suprimentos Ltda. Infosup Ltda. AGV Suprimentos Ltda. . . Endereo Rua Intel, 486 Rua FoxPro, 25 Rua Delphi, 30 . . Telefone 666-6666 680-6868 343-5643 . .
ARQUIVO DE ORIGEM DOS PRODUTOS

Fornecedor 0001 0002 0003 0002 0001 . . Produto 1.01.001 1.01.001 1.01.001 2.01.001 3.01.001 . . Preo 130,00 11,00 9,00 15,00 40,00 . .
Esta base de dados contm informaes de trs tipos, ou melhor, sobre trs entidades: Dados sobre produtos (entidade produto), armazenados no arquivo de produtos; Dados sobre fornecedores (entidade fornecedor), armazenados no arquivo de fornecedores e; Dados sobre a origem dos produtos (entidade origem do produto), ou seja, os produtos que so fornecidos por cada fornecedor e vice-versa, armazenados no arquivo de origem dos produtos. As informaes relativas a cada uma das entidades de interesse da organizao so armazenadas numa tabela ou arquivo de dados individual. Por sua vez, cada um destes arquivos formado por um conjunto de registros que descreve, atravs de atributos ou dados, cada entidade nele armazenada. Todos os registros de um arquivo, identificados pelas linhas de cada tabela, possui o mesmo formato, ou seja, o mesmo conjunto de dados ou atributos que descrevem as entidades.
26
Os registros so formados por um conjunto de dados, armazenados em campos, identificados pelas colunas das tabelas. Cada registro deve conter o conjunto de dados ou campos necessrios para descrever completamente cada entidade sobre a qual uma organizao necessita armazenar e obter informaes. Chave Primria ou Identificadora Em uma base de dados, para cada arquivo de dados existe pelo menos um arquivo de ndice de acesso que criado a partir de um atributo (ou campo) ou de um conjunto deles, para identificar cada registro de forma inequvoca. O conjunto de atributos ou campos utilizados para gerar este ndice conhecido como chave primria ou chave identificadora do arquivo. A chave primria , portanto, aquele atributo, ou conjunto de atributos, utilizado para distinguir ou identificar de forma nica cada registro dentro de um arquivo de dados. Uma chave primria no deve possuir atributos desnecessrios para a identificao dos registros. Se considera que uma chave primria no contm atributos ou campos desnecessrios quando, ao se eliminar qualquer um dos que a compem, a informao proporcionada pelos restantes no suficiente para identificar de forma inequvoca cada registro do arquivo de dados. No caso da base de dados de compras, exemplificada anteriormente, as chaves primrias de cada arquivo so: Arquivo dos Produtos: cdigo do produto. Arquivo dos Fornecedores: cdigo do fornecedor. Arquivo Origem dos Produtos: cdigo do fornecedor + cdigo do produto. Cada chave primria suficiente para identificar univocamente cada um dos registros dos arquivos da base de dados. Em conseqncia, em cada arquivo no dever haver mais do que um registro que possua o mesmo valor para sua chave primria. Em um SGBD adequadamente projetado deve ser gerado um erro se um usurio tentar incluir um novo registro cuja chave primria coincida com a de outro registro j existente no arquivo. Contudo, em muitos casos, principalmente em SGBDs mais simples para microcomputadores, ainda possvel incluir vrios registros com chaves primrias idnticas, sem que seja gerado um erro, o que causar srios problemas para a utilizao da informao armazenada na base de dados. ndices de Acesso Um ndice de acesso um arquivo auxiliar utilizado internamente pelo SGBD para acessar diretamente cada registro do arquivo de dados a ele associado. A operao de indexao (criao do arquivo de ndice pelo SGBD) ordena os registros de um arquivo de dados de acordo com os campos utilizados como chave e incrementa sensivelmente a velocidade de execuo de algumas operaes sobre o arquivo de dados, principalmente as relacionadas 27
com a localizao de registros. Normalmente, para cada arquivo de dados deve haver um ndice cuja chave de indexao seja idntica sua chave primria. Este ndice chamado de ndice primrio. Tambm possvel criar ndices para um arquivo de dados utilizando atributos (ou campos), ou conjuntos de atributos, diferentes dos da chave primria. Este tipo de ndice, chamado de ndice secundrio, utilizado para reduzir o tempo necessrio para localizar determinada informao dentro de um arquivo ou para classificar os registros do arquivo de acordo com ordem necessria para a obteno da informao desejada. Na figura 03 ilustrado um exemplo didtico simplificado do funcionamento de um arquivo de ndice associado um arquivo de dados. Normalmente, os registros de um arquivo de dados no esto ordenados, mas contm todos os dados que descrevem a entidade nele armazenada. Para acess-los de forma ordenada criado e mantido um arquivo ordenado (arquivo de ndice) que contm apenas a chave de ordenao (ou acesso) e o nmero do registro do arquivo de dados que a possui. Assim, localizando-se uma determinada chave no arquivo de ndice, torna-se possvel o acesso direto ao registro do arquivo de dados por ela identificado. Comparando um arquivo de dados a um livro, o processo seria equivalente a localizar o nmero da pgina na qual se encontra um determinado assunto atravs do ndice remissivo do livro e, em seguida, abrir o livro na pgina determinada para ter acesso direto ao assunto desejado, sem precisar folhear todo o livro at encontr-lo. A localizao das chaves no arquivo de ndice extremamente rpida, pois normalmente os SGBDs utilizam uma variao aperfeioada da tcnica de pesquisa binria, conforme esquematizado na figura 03. Atravs desta tcnica o arquivo de ndice inicialmente dividido em duas partes iguais, ou seja, em duas metades. A seguir, como o ndice est ordenado de acordo com a chave de pesquisa, verifica-se se a chave desejada est localizada na metade superior ou na inferior, comparando-a com o valor da chave central. Novamente a metade escolhida dividida ao meio, da o nome pesquisa binria, pois sempre se divide o ndice em duas partes, e o processo repetido at que seja localizada a chave desejada. Uma vez localizada a chave no arquivo de ndice, obtm-se o nmero do registro do arquivo de dados que a contm e realizado o acesso direto s informaes nele contidas. Utilizando-se a tcnica de acesso binrio, o tempo necessrio para ser localizada uma determinada informao no arquivo de dados praticamente independe da quantidade de registros que o mesmo possui.
28
Fig. 03 Esquema de arquivos de ndice e da busca binria
Projeto de Bases de Dados Antes de comearmos a examinar as tcnicas para o projeto e desenvolvimento de sistemas aplicativos (sistemas de informao automatizados), vamos fixar alguns dos objetivos que se deve alcanar no projeto e determinar, em particular, qual o resultado final que se deseja obter do processo de projeto de uma base de dados para um sistema aplicativo. Os principais objetivos do projeto de uma base de dados so: A base de dados deve ser capaz de armazenar toda a informao pertinente ao sistema: Ao se desenvolver um sistema aplicativo, se supe que sua base de dados deva armazenar e manter toda a informao relevante para a organizao. Um dos primeiros passos do projeto deve ser, portanto, determinar as entidades e seus respectivos atributos, que devero ser armazenados na base de dados. Apenas aps estas terem sido identificadas poderemos determinar o nmero de arquivos de dados necessrios e quais campos comporo os registros de cada um deles. Num sistema implantado em computadores de pequeno ou mdio porte, deve ser tomada ainda a deciso de dividir a informao em vrias bases de dados distribudas ou mant-la em uma s. A informao redundante deve ser eliminada: As implicaes deste objetivo podem no ser evidentes para o desenvolvedor inexperiente no projeto de bases de dados. A chave de sua importncia est na diferena entre informao duplicada e informao redundante. Em muitos casos necessrio duplicar dados contidos em arquivos diferentes para que se possa obter a informao necessria. Isso especialmente necessrio quanto forem estabelecidos relacionamentos (ligaes) entre arquivos de dados diferentes para podermos obter informaes completas sobre entidades complexas. Neste caso, se a duplicao for eliminada as informaes no mais podero ser obtidas. Portanto, a informao 29
duplicada mas necessria. A informao redundante a informao duplicada desnecessria, ou seja, se for eliminada no haver nenhuma perda, pois os relacionamentos ainda podero ser estabelecidos e a informao completa obtida. Alm disso, uma vez que desnecessria, a informao redundante ocupa espao precioso no disco do computador e, pior do que isso, podero ser geradas verses diferentes da mesma informao sem que seja possvel saber qual a verso correta. Nas sees seguintes sero examinadas tcnicas que nos ajudaram a definir a informao que dever estar contida em cada arquivo que formar a base de dados do sistema. O nmero de arquivos que deve compor a base de dados deve ser reduzido ao mnimo: Este objetivo contempla o fato de que, se a diviso dos arquivos de dados em outros menores pode ser interessante para eliminar certos problemas de atualizao e armazenamento, a existncia de um nmero muito elevado de arquivos na base de dados de um mesmo sistema aplicativo pode tornar incomoda e trabalhosa a manuteno de todos eles. Poderamos resumir dizendo que no conveniente que o nmero de arquivos de uma base de dados cresa incontrolavelmente. Os arquivos obtidos devem estar normalizados, a fim de minimizar os problemas de atualizao de dados: Certos tipos de arquivos so mais propensos do que outros a problemas de atualizao e manuteno. O desenvolvedor que est projetando uma base de dados deve saber detectar os arquivos que so potencialmente problemticos para poder normaliz-los. A normalizao de arquivos basicamente uma tcnica de decomposio ou subdiviso de um arquivo de dados em dois ou mais arquivos menores, atravs de um procedimento especfico para determinar a melhor maneira de efetuar a decomposio, de forma a evitar problemas de atualizao de dados nos arquivos. A tcnica de normalizao ser estudada mais adiante nesta apostila. Voc provavelmente deve ter percebido que os dois ltimos objetivos perseguem propsitos opostos. Normalmente, o projeto da base de dados de um sistema aplicativo o resultado de um compromisso equilibrado entre ambos, de acordo com as caractersticas do sistema que estiver sendo desenvolvido.
30
Etapas do Projeto de Sistemas

Introduo A partir da especificao dos requisitos, obtida na fase de levantamento, o projeto de um sistema de informao computadorizado pode ser dividido em cinco etapas, normalmente conhecidas como modelagem do sistema. Etapa 1 Modelagem de Processos
A primeira etapa do projeto de um sistema aplicativo o desenvolvimento de um esquema grfico denominado modelo de processos do negcio ou BPM (Business Process Model) que abrange o sistema como um todo. O modelo de processos do negcio descreve graficamente e de maneira simples o contexto do sistema, determinando o que ocorrer em cada rea ou funo da empresa que ser afetada ou envolvida, as operaes ou processos a serem desempenhados, os arquivos de dados necessrios e o fluxo de dados entre eles. A simplicidade do modelo de processos do negcio deve-se ao fato de que apenas quatro smbolos so utilizados para produzir um esquema que representa os usurios externos, os processos e os dados de qualquer sistema de informao, no nvel de detalhamento desejado. As tcnicas para construo de modelos de processos do negcio so discutidas mais adiante, mas basicamente sua utilizao permite: 1. Fixar a fronteira entre o sistema e a rea da empresa/organizao por ele abrangida, ou seja, o que no estiver representado pelo modelo de processos do negcio no faz parte do sistema que est sendo projetado. 2. Mostrar a pessoas sem qualquer conhecimento de informtica, mas familiarizadas com a administrao da empresa, a estrutura de funcionamento do sistema e como os dados sero processados, pois a compreenso do modelo de processos do negcio simples. 3. Interrelacionar tanto os dados armazenados no sistema como os processos que transformam estes dados, representando de forma completa o sistema. De acordo o autor ou metodologia adotada, h vrias denominaes e formas para se representar o modelo de processos do negcio. Uma das mais tradicionais, e que adotaremos nesta apostila a proposta por Gane & Sarson, que originalmente o denominaram de Diagrama de Fluxo de Dados (DFD). Etapa 2 Modelagem de Dados
A partir do modelo de processos do negcio, a segunda etapa consiste na elaborao de uma anlise de entidades e relacionamentos, ou seja, na definio dos objetos de informao ou entidades de interesse para os usurios, cujos dados devem ser armazenados e relacionados atravs dos arquivos que formaro a base de dados do sistema. Para ilustrar a estrutura dos dados do sistema, construdo um diagrama 31
contendo cada entidade identificada e linhas interligando-as, representando o relacionamento entre elas. Uma das principais vantagens obtidas com a construo deste diagrama, denominado modelo relacional de dados ou RDM (Relational Data Model) o conhecimento do tipo de relacionamento existente entre as entidades ou objetos que comporo a base de dados do sistema: um-para-um, um-para-muitos ou muitos-paramuitos. Atravs do RDM, um relacionamento do tipo muitos-para-muitos deve ser subdividido em dois relacionamentos um-para-muitos, criando-se um objeto ou entidade especial denominada "entidade intersectora ou associativa". Alm disso, para cada relacionamento um-para-um, verifica-se se cada entidade verdadeiramente nica ou pode ser formada por um conjunto de entidades de menor nvel. A construo do RDM, que ser discutida mais adiante, fornece uma viso de alto nvel dos arquivos de dados envolvidos no sistema, ajuda a descobrir os objetos de informao ou entidades que no foram detectados pelo BPM e a simplificar a estrutura de dados do sistema. Alm disso, atravs do RDM so definidas as chaves identificadoras ou primrias de cada arquivo de dados, bem como suas chaves estrangeiras, necessrias para estabelecer o relacionamentos entre as entidades. Atravs destas chaves os registros dos arquivos de dados podero ser acessados e processados para fornecer as informaes necessrias. Aps a construo do RDM, nesta etapa tambm elaborada uma lista detalhada com as caractersticas de todos os dados que sero armazenados em cada arquivo que formar a base de dados do sistema. Os dados devero ser descritos em termos de seus nomes completos, nomes cdigo, tipo, tamanho, preciso, domnio (valores vlidos), regras de validao, mscaras de formatao etc., de forma a permitir a implementao fsica da base de dados atravs do SGBD escolhido. Etapa 3 Normalizao
Utilizando todas as informaes disponveis at agora para descrever a estrutura de dados do sistema, na terceira etapa devemos adequar os arquivos de dados que formaro a base de dados do sistema ao processamento pelo computador. Como ser descrito mais adiante, os arquivos de dados ou tabelas do sistema devero ser simplificadas ou normalizadas, para que possam ser fisicamente criadas no disco do computador e atualizadas com segurana e consistncia pelo sistema. Atravs da tcnica de normalizao se garante que todas as tabelas necessrias sero criadas, todos os dados de todas as entidades estaro nelas armazenadas e haver um mnimo de duplicao de dados para interlig-las, eliminando-se a redundncia. As regras a serem seguidas para a normalizao de arquivos de dados fundamentalmente determinam que num arquivo ou tabela adequadamente simplificada, cada campo nochave deve depender da chave inteira (chave primria), e apenas desta chave. A aplicao desta regra aos dados que devero ser armazenados, de acordo RDM, fornecer um conjunto de arquivos mais simplificados e mais adequados para a implementao da base 32
de dados do sistema. Neste conjunto de arquivos deveremos ainda rever os dados que especificarmos para evitar a criao de sinnimos (nomes diferentes denotando a mesma coisa) e homnimos (nomes iguais denotando coisas diferentes). Nomes exclusivos e nicos, definidos atravs de uma conveno consistente, devero ser utilizados para denotar cada dado a ser armazenado nos arquivos do sistema. Etapa 4 Reconstruo do BPM e do RDM
Como resultado da anlise de entidades e relacionamentos e do processo de normalizao dos arquivos de dados, nesta etapa deve ser reconstrudo o BPM, para refletir uma viso mais precisa dos processos e dados que iro compor o sistema. Como resultado do processo de normalizao dos arquivos de dados, nesta etapa tambm deve tambm ser reconstrudo o RDM, para refletir uma viso mais precisa dos dados e relacionamentos que iro compor a base de dados do sistema. Na verdade, o processo de projeto de um sistema de informao interativo e convergente, ou seja, cada etapa subsequente pode afetar as anteriores que, portanto, devem ser reconstrudas at que estejam todas coerentes e consistentes. Etapa 5 Definio dos Mdulos do Sistema
Na quinta e ltima etapa do projeto para o desenvolvimento de um sistema de informao automatizado, dividimos o BPM reconstrudo na quarta etapa em mdulos menores, ou seja, em partes ou subsistemas que sero desenvolvidos como unidades ou mdulos individuais. conveniente representar a definio dos mdulos do sistema em forma de uma rvore que traduza a hierarquia de operao ou execuo do sistema. Normalmente, cada mdulo, submdulo e suas correspondentes operaes sero executadas atravs de listas ou "menus de opes". A rvore do sistema deve representar a diviso e a hierarquia dos mdulos e submdulos que comporo o sistema e a forma como suas operaes sero desencadeadas. Aps a definio da rvore ou diagrama hierrquico do sistema, deve ser elaborada a especificao detalhada de cada mdulo definido, necessria para se implementar o sistema. Como veremos mais adiante, a especificao dos mdulos deve constar de: Um trecho detalhado do BPM do sistema no qual o mdulo se encaixa no restante do sistema; Um trecho da rvore do sistema atravs da qual o mdulo poder ser acessado e suas operaes executadas; Um trecho detalhado do RDM com os arquivos de dados acessados pelo mdulo; A definio dos formatos das telas ou formulrios e relatrios envolvidos na execuo do mdulo; 33
As definies relativas s funes e operaes a serem implementadas pelos processos que compem o mdulo em questo, retratando as regras de negcio ou lgica necessria, a ser implementada nos programas; As definies relativas ao dilogo do sistema com o usurio.
Implementao do Sistema
Introduo Uma vez especificados os mdulos que comporo o sistema, passa-se para a sua implementao atravs de uma linguagem de programao ou ferramenta de desenvolvimento adequada. Contudo, convm ressaltar, que as tcnicas de especificao que utilizamos at agora so todas estticas, no sentido de que podem ser interpretadas como se fossem plantas arquitetnicas do projeto de uma casa. Prototipao Antes de atingir o desenho do formato das telas do sistema, teremos produzido apenas quadros abstratos (BPM, RDM etc.) que representam a estrutura do sistema atravs de um modelo conceitual, mas no mostram nada de concreto aos usurios. Por este motivo, quanto maior o projeto, para reduzir os riscos de incompreenso dos usurios, atrasos e fracassos, deve-se adotar a tcnica de implementao de cima para baixo (top-down). Essencialmente, ela envolve primeiro a criao de um esqueleto ou prottipo do sistema, apenas o suficiente para testar a integrao de seus diversos mdulos, antes de desenvolver os seus programas de forma completa e detalhada. Adotando a implementao de cima para baixo possvel testar a integrao dos mdulos e submdulos no incio da codificao dos programas, antes que um grande investimento tenha sido feito. A implementao dever ser planejada como uma srie de verses, cada uma testando determinadas partes do sistema (mdulos ou conjuntos de mdulos), sucessivamente tratando os dados mais complexos e/ou realizando mais operaes, at que todo o sistema tenha sido implementado de forma completa, atendendo todas as necessidades dos usurios. Para os usurios, os formulrios, os relatrios, os processos de clculo e outras entradas/sadas so o sistema. Porm, mesmo j tendo desenhado o formato das telas e dos relatrios, o dilogo com o usurio no esttico; ele depende de cada ao do operador, e muitas vezes difcil descrever e visualizar o que o sistema far no papel. Devido facilidade de desenvolvimento que hoje oferecem determinadas ferramentas, a partir da especificao detalhada dos mdulos do sistema, relativamente rpido criar uma verso prototipada de um mdulo especfico, que efetivamente apresente formulrios/telas e aceite entradas, de modo que os usurios possam em curto espao de tempo obter 34
experincia direta e concreta de como podero trabalhar com o sistema, at que ele seja entregue por completo. Se por acaso os usurios precisarem efetivamente 20 dados para descrever uma determinada entidade, e apenas 18 tiverem sido identificados na fase de projeto, ento o trabalho com o prottipo rapidamente permitir a identificao dos dados faltantes. Alm disso, os usurios j podero iniciar a alimentao dos dados cadastrais do sistema, para que, quando os demais mdulos j estiverem finalizados, j possam ser utilizados. Infelizmente, a velocidade com que um prottipo pode ser produzido atravs das ferramentas modernas, estimulou certas pessoas a minimizarem o esforo que deve ser investido em definir detalhadamente o projeto do sistema, antes de comear a desenvolver o prottipo. Nesse sentido, pode-se distinguir dois tipos de prototipao: a de descoberta e a de refinamento. Prototipao de Descoberta Neste caso, antes de ser produzido um prottipo, realizada apenas a anlise informal das necessidades, para refletir o que compreendido como aquilo que os usurios desejam. A experincia de utilizar o prottipo motiva os usurios a pensarem mais concretamente a respeito de suas necessidades, e o prottipo rapidamente revisto diversas vezes, medida que os usurios descobrem, especificam e detalham mais suas necessidades. Quando este mtodo bem sucedido podem haver considerveis vantagens, pois sistemas inteiros podem ser entregues a partir do zero em algumas semanas. Entretanto, o risco de fracasso elevado, principalmente quando o desenvolvedor no possui experincia prvia com o tipo de sistema que est sendo desenvolvido. Os dois maiores perigos com os quais podemos nos defrontar neste tipo de prototipao so: 1. O sistema pode ficar to grande que tanto os usurios como o desenvolvedor no conseguir manter todas as funes e dados na memria, perdendo completamente o controle do projeto. Ningum mais conseguir definir a abrangncia do sistema ou ter certeza de como suas partes se encaixam. 2. O sistema pode entrar numa iterao aparentemente interminvel de tentativas e revises, geralmente porque os usurios e o desenvolvedor so levados a se concentrar nos detalhes fsicos do sistema, ao invs de na finalidade do sistema para a empresa. A prototipao por descoberta uma abordagem arriscada, sendo recomendvel apenas para aqueles casos, no muito raros, em que os prprios usurios no conseguem ou no podem, a princpio, definir suas necessidades, pois ainda as esto descobrindo. Essa situao muito comum no desenvolvimento de sistemas de apoio a deciso. Prototipao de Refinamento A prototipao de refinamento comea a partir da especificao detalhada dos mdulos do sistema, sendo mais significativa para aqueles mdulos em que haver um intenso dilogo 35
interativo entre o usurio definido apenas a partir do desenvolvimento moderna, produzido e refinado um completo.
e o sistema, cujo funcionamento no pode ser facilmente formato de telas ou relatrios. Utilizando uma ferramenta de que possua um gerador automtico de programas, pode ser prottipo de cada mdulo at que o sistema todo esteja
A prototipao de refinamento permite descobrir pequenas falhas no projeto, tais como no incluir um determinado dado numa tela ou relatrio, pois, afinal, o usurio sempre conhecer seu servio melhor do que o desenvolvedor. Por outro lado, poder tambm mostrar a inviabilidade de se colocar uma quantidade muito grande de dados numa nica tela ou num nico relatrio, e assim por diante, at que, tanto os usurios como o desenvolvedor estejam satisfeitos com o funcionamento do sistema. Via de regra, os desenvolvedores de sistemas devem apresentar aos usurios apropriados um prottipo de cada mdulo do sistema o mais cedo possvel, para que, atravs da prototipao de refinamento, com o efetivo envolvimento dos usurios no desenvolvimento, o sistema possa ser concludo rapidamente, com a certeza de sucesso. Entretanto, mesmo utilizando a prototipao de refinamento, est-se sujeito a enfrentar um ciclo interminvel de revises, o que determina que a mesma deve ser cuidadosamente controlada, para que as revises convirjam para o formato final do sistema. Quando as revises comearem a divergir deve-se interromper o processo e, atravs de uma reunio de consenso com os usurios, avaliar o estado atual do sistema e tomar decises que rapidamente determinem sua convergncia para um formato final. Na maioria dos casos a prototipao por refinamento a melhor alternativa, suas principais vantagens so: elaborado um projeto detalhado do sistema que automaticamente far parte de sua documentao final; Em curso espao de tempo (algumas semanas) os usurios j comeam a utilizar e testar o sistema, fornecendo sugestes para o seu refinamento, participando, desta forma, efetivamente do desenvolvimento; Enquanto os mdulos mais complexos vo sendo desenvolvidos, os usurios j iniciam o cadastro de dados no sistema, permitindo, posteriormente, os testes dos mdulos mais complexos com dados reais; Ao final do desenvolvimento, o sistema estar exatamente de acordo com as necessidades dos usurios e estes o compreendero completamente, alm de j estarem treinados para sua operao; O sucesso do sistema estar praticamente garantido, pois os usurios desenvolvem o sistema em conjunto, percebendo todas as vantagens, desvantagens, dificuldades e facilidades de cada detalhe de implementao. Alm disso, passam a ter uma boa noo das implicaes e do tempo necessrio para qualquer modificao. 36
Modelo de Processos do Negcio (BPM)

Introduo O modelo de processos do negcio ou business process model (BPM) uma das principais tcnicas utilizadas no projeto de sistemas de informao. O BPM um diagrama grfico baseado apenas em quatro smbolos que mostra a estrutura do sistema e sua fronteira, ou seja, todas as relaes entre os dados (arquivos e fluxos de dados), os processos e funes que transformam estes dados e o limite entre o que pertence ao sistema e que est fora do sistema. Os smbolos utilizados para construir o BPM so muito simples, sendo muito fcil seu entendimento, quer seja por pessoal especializado em informtica, quer seja por pessoal no especializado, mas conhecedor da empresa. Aps uma rpida explicao, qualquer pessoa pode ler um BPM e entender a estrutura e a fronteira de um sistema de informao automatizado. Smbolos do Modelo de Processos do Negcio Para a construo de um BPM so utilizados apenas quadro smbolos: entidade externa, fluxo de dados, processo e arquivo de dados. Alm deles, so tambm utilizadas algumas convenes, que a seguir descreveremos. Entidades Externas Entidades externas representam as origens e/ou destinos de fluxos de dados para dentro e para fora do sistema. Elas, por definio, esto fora do sistema em considerao, e so representadas por um quadrado que recebe um sombreamento em dois dos seus lados para dar um certo relevo. No centro do quadrado escrito o nome da entidade externa que est sendo representada, como ilustrado na Fig. 04. As entidades externas correspondem fronteira do sistema, ou seja, o que ocorre dentro de uma entidade externa no faz mais parte do sistema. Entretanto, se voc precisar descrever o que ocorre numa entidade externa para entender o sistema, significa que a fronteira do sistema mais ampla do que est sendo considerada e que, portanto, a entidade externa em questo deve fazer parte do seu sistema. Uma entidade externa pode representar um grupo de pessoas, como clientes ou fornecedores, um outro sistema, como um sistema de folha de pagamento, ou uma nica pessoa, como um diretor ou o presidente da empresa. Elas recebem ou fornecem dados ao sistema, mas no fazem parte dele.
37
Fig. 04 Entidades externas
Quando uma entidade externa fornece dados para o sistema, deve haver um fluxo de dados saindo da entidade externa em direo ao sistema. Quando uma entidade externa recebe dados do sistema, deve haver um fluxo de dados do sistema para a entidade externa, como ilustrado pela Fig. 05.
Fig. 05 Fluxo de dados de e para uma entidade externa
Muitas vezes, por questes de clareza ao se desenhar o BPM, necessrio duplicar as entidades externas para evitar que longas setas de fluxos de dados saiam de um lado do diagrama para o outro, congestionando demasiadamente o desenho. Neste caso, por conveno, coloca-se um par de nmeros entre parnteses num canto do smbolo da entidade externa. O segundo nmero informa ao leitor do BPM quantas ocorrncias da mesma entidade externa esto representadas no diagrama, enquanto que o primeiro indica qual ocorrncia em questo, como ilustra a Fig. 06. Portanto, em BPMs muito complexos, nos quais podero existir muitas repeties da mesma entidade externa, conveniente colocar nmeros entre parnteses, como ilustrado
38
na figura a seguir, para mostrar quantas ocorrncias da mesma entidade externa esto representadas e qual o nmero de cada entidade externa repetida.
Fig. 06 Duplicao de entidades externas no BPM
Fluxos de Dados O caminho atravs do qual uma ou mais estruturas ou conjuntos de dados fluem de um elemento do BPM para outro representado por uma seta indicando um fluxo de dados. Normalmente, cada seta de fluxo de dados deve possuir um nome que descreve a estrutura ou conjunto de dados que est fluindo de um elemento para o outro. Eventualmente, diversas estruturas de dados podero ser representadas passando pelo mesmo fluxo de dados. Alm disso, muitas vezes, para simplificar o diagrama, conveniente ter setas com duas pontas, indicando fluxos de dados que entram e saem de um determinado elemento. Como regra geral, as setas representando os fluxos de dados so sempre desenhadas horizontal ou verticalmente. Setas diagonais ou poligonais no devem ser utilizadas. Apenas quando o contedo de um fluxo de dados for realmente bvio, ele no precisa necessariamente receber nomes. A Fig. 07 ilustra representaes de fluxos de dados. Os fluxos de dados indicam movimentos de dados de um elemento do BPM para outro, mas no representam nenhuma considerao temporal, ou seja, no indicam a freqncia e nem quando uma estrutura de dados segue de um lugar para outro. Neste caso, se dependncias temporais forem importantes para a anlise, deve ser desenvolvido um quadro de tempo especial, fora do BPM.
39
Fig. 07 Fluxos de dados
Processos Um processo ou uma funo, que capta, envia, grava ou transforma os dados de alguma maneira, representado por um retngulo com cantos arredondados, como ilustra a Fig. 08.
Fig. 08 Um processo
Normalmente, na sua parte superior, o smbolo de um processo recebe um nmero seqencial identificador. No seu corpo deve haver uma descrio bem resumida da funo ou processo que est sendo representado; via de regra atravs de um verbo no infinitivo com o objeto sobre o qual a ao est sendo realizada. Opcionalmente, na parte inferior do smbolo do processo, poder estar escrito o nome do departamento, do programa ou de algum outro agente que realize fisicamente tal processo ou funo para o sistema. Os processos no devem ser duplicados num BPM, entretanto, quando os processos forem realmente idnticos e a duplicao for inevitvel, deve ser utilizada a mesma conveno das entidades externas, isto , um par de nmeros entre parnteses num dos cantos do processo.
40
Como regra geral, os tratamentos de erro e de excees no devem ser representados em um BPM, a menos que sejam muito relevantes para os usurios do sistema. O BPM deve ser visto como uma ferramenta de planejamento do sistema, e no como sua especificao detalhada. Sua finalidade mostrar o fluxo normal de dados entre os principais elementos, e no os detalhes de implementao do sistema. Arquivos de Dados Um retngulo alongado com o lado direito aberto utilizado para representar um ou mais arquivos de dados ou tabelas que comporo a base de dados do sistema. Por princpio, cada arquivo de dados deve ser representado individualmente no BPM. Contudo, quando dois ou mais arquivos contiverem dados a respeito da mesma entidade, e normalmente forem acessados juntos, pode-se represent-los por um nico smbolo, separando seus nomes por uma barra.
Fig. 09 Representao de arquivos de dados
Na extremidade do lado esquerdo do smbolo de arquivo de dados, separado por um trao vertical, normalmente colocado um nmero seqencial ou um cdigo para identificar o arquivo de dados que est sendo representado. Da mesma forma que com os outros elementos, os arquivos de dados tambm podero ser repetidos para evitar um emaranhado de fluxos de dados de um canto a outro do BPM. Um par de nmeros entre parnteses deve ser colocado na extremidade esquerda do smbolo de arquivo de dados para indicar sua repetio. O primeiro nmero deve identificar o nmero de cada ocorrncia e o segundo a quantidade total de ocorrncias do mesmo arquivo de dados no BPM, como ilustra a Fig. 10.
Fig. 10 Duplicaes de arquivos de dados
Quando um arquivo de dados estiver armazenando dados sobre um objeto, como um produto ou um cliente, ele estar sujeito a um volume relativamente baixo de transaes rotineiras de manuteno (incluses, alteraes e excluses de dados). Normalmente, 41
esses fluxos rotineiros de manuteno so representados por uma entidade externa alimentando dados para dentro de um processo que atualiza o arquivo de dados, como ilustrado pelo trecho de diagrama da Fig. 11.
Fig. 11 Manuteno de um arquivo de dados
Quando diversos sistemas compartilharem um mesmo arquivo de dados, o sistema que estiver sendo projetado poder acessar e atualizar arquivos de dados que tambm so acessados e atualizados por outros sistemas relacionados. Neste caso, conveniente mostrar este fato explicitamente no BPM, atravs da notao ilustrada na Fig. 12. Esta notao uma exceo regra de que os dados no devem ir diretamente de uma entidade externa para um arquivo de dados, sem passar por um processo responsvel pela transferncia dos dados.
Fig. 12 - Atualizao de arquivos de dados por sistemas diferentes
Construo do Modelo de Processos do Negcio De acordo com a complexidade do sistema a ser desenvolvido, o modelo de processos do negcio pode assumir um tamanho considervel. Por este motivo, recomenda-se manter os processos dos BPMs dentro de um "tamanho administrvel". Este tamanho administrvel totalmente subjetivo mas, em geral, nenhum processo deve necessitar mais do que duas ou trs pginas escritas para ser descrito. 42
Entretanto, se um BPM contiver um processo que o analista julgue ser superior ao "tamanho administrvel", h duas alternativas: fisso e exploso. Com a fisso, o processo original substitudo no BPM por um conjunto de subprocessos, mais simples, que a ele so equivalentes, mas que tornam mais fcil o entendimento do sistema. Com a exploso, o processo original mantido no BPM a nvel do sistema como um todo, mas cria-se um novo BPM, de nvel inferior, formado por processos mais simples e pelos arquivos de dados que vierem a ser necessrios, mas que no foram explicitados no desenvolvimento do BPM a nvel do sistema como um todo. Recomenda-se que se evite a exploso do BPM, e que um sistema de informao seja representado por um nico modelo de processos do negcio. Cada processo contido no BPM no deve necessitar mais do que quatro pginas para ser descrito, para que no ultrapasse um "tamanho administrvel" e seja fcil de ser explicado. Finalmente, aps haver desenhado uma primeira verso do BPM do sistema, recomendvel utilizar a relao de verificao apresentada a seguir para corrigir os erros e deficincias mais comuns que podem ocorrer e para se aprimorar o BPM. Lista de Verificao para o BPM 1. Todos os processos possuem uma descrio sucinta do tipo "verbo e objeto"? 2. Todos os arquivos de dados representam objetos de informao de interesse do sistema? 3. Todos os processos e arquivos de dados possuem pelo menos um fluxo de dados de entrada e um fluxo de dados de sada? 4. Os fluxos de dados sem identificao podem ser facilmente identificados? 5. Todos os fluxos de dados comeam ou terminam em um processo? 6. Todos os fluxos de dados possuem pelo menos uma seta de direo? 7. H algum arquivo de dados com apenas um fluxo de entrada e um fluxo de sada que no sejam arquivos intermedirios ou temporrios? 8. Todos os processos foram representados dentro de um "tamanho administrvel" e facilmente compreensvel? 9. Todos os arquivos de dados foram representados? 10.No h nenhum fluxo de dados faltando?
43
Lista de Recomendaes para o BPM 1. Os BPMs so mais legveis se as entidades externas forem dispostas nas bordas do diagrama, de forma que a fronteira do sistema (ou contexto) se situe dentro do contorno de entidades externas. Uma linha de contexto pode ser desenhado para ressaltar este fato. 2. Se os fluxos de dados principais ocorrerem do lado esquerdo para o lado direito do diagrama, a leitura se tornar mais fcil e rpida. 3. As duplicaes de smbolos devem ser mantidas ao mnimo, e consistir de um nmero aceitvel de linhas de fluxo de dados cruzando umas com as outras. 4. Inicie a construo do BPM pelas entidades externas, em seguida pelas entradas que delas so originadas, juntamente com as sadas que iro para elas. 5. O primeiro desenho de um BPM sempre ter um papel de rascunho. Sua finalidade a identificao de todas as entidades externas, processos e arquivos de dados que formaro o sistema, alm de se colocar as ligaes ou fluxo de dados entre eles. Verses posteriores aprimoraro as definies e o desenho. 6. Ao desenhar um primeiro rascunho do BPM, pense em como o sistema funciona realmente, qual a entrada ou processo que o inicia, e comece o desenho por a. 7. A ordem mais lgica para se desenhar o BPM definir a entidade externa ou processo que gera uma entrada de dados, depois o processo que trata essa entrada, em seguida os arquivos de dados que so utilizados para armazen-la e para garantir o funcionamento dos processos afetados e, finalmente, definir as sadas que so geradas pelo processo. O primeiro rascunho do BPM deve ser feito a mo livre, escrevendo os smbolos e as linhas dos fluxos de dados muito levemente, a lpis. Procure ser abrangente, mesmo que o diagrama inicialmente tenha uma forma desajeitada, deixe-o assim. O segundo rascunho e os posteriores podem ser produzidos utilizando uma ferramenta de software automatizada. Embora uma ferramenta grfica genrica possa ser utilizada, h vrias ferramentas de software especificamente projetadas para a modelagem ou projeto lgico de sistemas de informao. A maioria delas tambm est integrada com um recurso de dicionrio de dados, que pode armazenar os detalhes do modelo lgico do sistema. Algumas at possuem recursos de desenho de telas que podem ser utilizados na prototipao do sistema. Essas ferramentas de software passaram a ser conhecidas como ferramentas CASE (Computer Assisted Software Engineering - Engenharia de Software Apoiada por Computador) e um bom exemplo o Silverrun, que utilizaremos no curso. A Fig. 13 na pgina seguinte apresenta um exemplo simplificado de um modelo de processos do negcio completo, a nvel de sistema como um todo.
44
45
Modelo Relacional de Dados (RDM)

Introduo Uma das definies mais importantes para o projeto de sistemas de informao a definio dos objetos de informao de interesse da empresa ou organizao para a qual o sistema ser construdo, pois para satisfazer os objetivos do sistema precisamos armazenar dados a respeito deles. Os objetos de informao so geralmente entidades ou eventos, por exemplo: clientes, fornecedores, produtos, vendas, compras e cobranas. As entidades so objetos que existem durante um determinado tempo (produtos, clientes, fornecedores etc.). Os eventos so objetos que ocorrem num determinado momento especfico (vendas, compras, cobranas, produes etc.). Uma entidade poder ter um ou mais eventos a ela associados (uma ou mais vendas, uma ou mais cobranas etc.). Por outro lado, um evento pode representar a associao de uma ou mais entidades (uma venda de diversos produtos para um cliente, ou uma compra de diversos produtos de um fornecedor). Cada entidade ou evento deve ser representado pelo menos por um arquivo de dados. Consequentemente, algo que no requeira pelo menos dois dados para ser descrito no ser uma entidade ou um evento, e sim um atributo ou dado de um outro objeto de informao. Desta forma, uma data no uma entidade ou um evento, mas apenas um dado ou atributo de uma entidade, como por exemplo a "data de admisso" da entidade funcionrio, ou um dado de um evento, como por exemplo a "data da compra" de um evento compra. Como regra geral, cada arquivo de dados, definido pelo modelo de processos do negcio, armazena os dados que descrevem entidades e eventos de interesse do sistema de informao. Normalmente, cada entidade que compe a base de dados de um sistema aplicativo poder estar relacionada com outras. Assim, por exemplo, um cliente poder estar relacionado com vrias vendas, uma venda com vrios produtos, um vendedor com vrias vendas, e assim por diante. Portanto, tendo em vista que as entidades de uma base de dados esto relacionadas, e que, atravs desse relacionamento so geradas informaes, como por exemplo, todos os produtos vendidos a um cliente, importante definir todos os relacionamentos entre as entidades e o seu correspondente tipo. Por identificar todas as entidades que formaro a base de dados, por definir todos os relacionamentos entre elas e por descrever o tipo de cada relacionamento, o modelo relacional de dados (RDM) fundamental para o projeto de qualquer base de dados. O RDM mostra os trs tipos de relacionamento possveis entre as entidades e os eventos de um BPM: um-para-um (1,1), um-para-muitos (1,N) e muitos-para-muitos (N,N). 46
Cada entidade representada por um retngulo, e o relacionamento entre elas por uma linha unindo os retngulos. O tipo do relacionamento representado por um par de nmeros na extremidade da linha de relacionamento: 1 identifica um relacionamento com uma nica entidade e N identifica um relacionamento com muitas entidades e 0 identifica o relacionamento com nenhuma entidade. A descrio do relacionamento deve ser feita ao longo das linhas que interligam as entidades relacionadas. Na Fig. 14 representado o relacionamento entre PESSOA e DEPARTAMENTO. O par de nmeros 1,1 indica que uma pessoa trabalha em um nico departamento. Por outro lado, o par de nmeros 0,N indica que num departamento podem trabalhar nenhuma ( 0 ) ou vrias pessoas ( N ).
Fig. 14 Relacionamento 0:N entre PESSOA e DEPARTAMENTO
Portanto, uma pessoa est relacionada a um departamento (1,1), e um departamento est relacionado a nenhuma ou vrias pessoas (0,N).
Fig. 15 - Relacionamento 1:N entre VENDA E ITENS DA VENDA
No exemplo da Fig. 15 cada VENDA envolve um ou mais ITENS ou produtos vendidos (1,N), mas um ITEM ou produto parte de apenas uma venda (1,1).
Fig. 16 Relacionamento N:N entre FORNECEDOR e PRODUTO
47
No exemplo da Fig. 16 cada FORNECEDOR fornece um ou mais produtos (1,N) e cada PRODUTO pode ser fornecido por um ou mais fornecedores (1,N). Um relacionamento entre duas entidades ou eventos poder ser lido em qualquer uma das direes como "objeto 1 est relacionado ao objeto 2" ou o "objeto 2 est relacionado ao objeto 1". Por exemplo, "um fornecedor fornece um ou vrios produtos (1,N)" ou "um produto fornecido por um ou vrios fornecedores (1,N)". Quando um relacionamento for suficientemente bvio, no ser necessrio indentific-lo atravs de uma palavra descritiva, como ilustrado na Fig. 17. Relacionamentos Um-para-Um Ao ser identificado um relacionamento um-para-um (1,1), deve-se inicialmente verificar se os dois objetos relacionados so realmente distintos ou se podem ser unidos em um nico. Se cada objeto for identificado pela mesma chave primria e se ambos se completarem, h uma forte razo para unir os dois objetos em um nico. Por exemplo, tomemos as entidades PRODUTO e ESTOQUE:
Fig. 17 - Relacionamento 1:1 entre PRODUTO e ESTOQUE
Como cada PRODUTO armazenado no ESTOQUE, podemos considerar apenas uma entidade PRODUTO ESTOCADO:
Fig. 18 - Entidade PRODUTO ESTOCADO
Neste caso, as entidades PRODUTO e ESTOQUE no so realmente distintas e, por esse motivo, devemos armazen-las num nico arquivo de dados, pois o saldo no estoque apenas um atributo de cada produto. Se os dois objetos forem realmente distintos, cada um dever ser identificado por um dado chave que o distinga de forma inequvoca dos demais. Este dado chave denominado chave primria do objeto, e sublinhado no diagrama do RDM, como ilustrado na Fig. 19. 48
O relacionamento entre os dois objetos dever ser realizado atravs de uma chave de relacionamento, denominada chave estrangeira. A chave estrangeira dever estar indicada no objeto relacionado, como ilustrado na Fig. 19. A chave estrangeira recebe este nome porque, na verdade ela no um atributo do objeto relacionado, mas sim a chave primria do objeto ao qual este se relaciona.
Fig. 19 Relacionamento um-para-um e suas chaves
No caso do relacionamento um-para-um (1,1) entre uma disciplina e um professor que a leciona, temos a chave primria da DISCIPLINA (cdigo que a identifica) e a chave primria do PROFESSOR (nmero que o identifica). Se admitirmos que um PROFESSOR est relacionado a uma nica DISCIPLINA, ento a chave estrangeira, que realiza o relacionamento (cdigo da disciplina) deve ser armazenada no arquivo que descreve o professor, e aponta ou determina a disciplina por ele lecionada., como ilustrado na Fig. 19. Portanto, no arquivo PROFESSOR, o dado "cdigo da disciplina" uma chave estrangeira, significando que se trata de um dado do arquivo DISCIPLINA, mas que precisa existir no arquivo PROFESSOR para permitir o relacionamento entre ambos. Note que neste relacionamento entre DISCIPLINA e PROFESSOR, um professor pode apenas lecionar uma disciplina. Uma outra forma alternativa de relacionar professores e disciplinas seria admitir que uma disciplina somente ministrada por um professor. Isto significa incluir a chave estrangeira "nmero do professor" no arquivo DISCIPLINA.
Fig. 20 - Chave estrangeira PROFESSOR x DISCIPLINA
49
Embora estas duas solues sejam possveis para o relacionamento entre PROFESSOR e DISCIPLINA, nenhuma delas est totalmente correta. Uma soluo melhor deve permitir que um professor possa lecionar vrias disciplinas ou que uma disciplina possa ser ministrada por vrios professores. Ou seja, o relacionamento entre PROFESSOR e DISCIPLINA no um-para-um (1,1), mas pelo menos um-para-muitos (1,N). Estes exemplos servem para apresentar a anlise que deve ser feita ao se projetar um relacionamento um-para-um: O relacionamento sempre ser um-para-um? H alguma possibilidade de no futuro ele se tornar um-para-muitos? Qual forma poder se adaptar a uma possvel mudana futura do sistema? Em que arquivo dever ser includa a "chave estrangeira" para ser utilizada como apontadora do relacionamento? Relacionamentos Um-para-Muitos Um relacionamento um-para-muitos (1,N) ocorre quando um nico objeto (entidade) est relacionado com vrios outros objetos. Como cada objeto de informao sempre possui um arquivo de dados contendo seus atributos, a chave primria do "objeto um" deve ser uma "chave estrangeira" no arquivo que descreve o "objeto muitos", podendo ser parte de sua chave primria ou no. No exemplo ilustrado pela Fig. 21, mostrando o relacionamento entre uma DISCIPLINA (objeto um) e vrios PROFESSORES (objeto muitos), o atributo "cdigo da disciplina" a chave estrangeira de PROFESSOR.
Fig. 21 - Relacionamento um-para-muitos entre DISCIPLINA e PROFESSOR
Neste caso, uma disciplina pode ser ministrada por vrios professores (1,N), mas um professor somente pode lecionar uma nica disciplina (1,1). J no exemplo ilustrado pela Fig. 22, mostrando o relacionamento entre um PROFESSOR (objeto um) e vrias DISCIPLINAS (objeto muitos), o atributo "nmero do professor" a chave estrangeira de DISCIPLINA.
50
Fig. 22 - Relacionamento um-para-muitos entre PROFESSOR e DISCIPLINA
Neste caso, um professor pode ser lecionar vrias disciplinas (1,N), mas uma disciplina pode ser ministrada somente por um professor (1,1). Relacionamentos Muitos-para-Muitos Se analisarmos os exemplos anteriores, perceberemos que o relacionamento mais correto entre PROFESSOR e DISCIPLINA no um-para-um e nem um-para-muitos, mas sim muitos-para-muitos. Ou seja, um professor pode lecionar muitas disciplinas e uma disciplina pode ser ministrada por muitos professores. Um relacionamento muitos-para-muitos sempre deve ser resolvido por dois relacionamentos um-para-muitos (1,N), pois no possvel que tanto PROFESSOR como DISCIPLINA recebam chaves estrangeiras. Neste caso, inicialmente, as chaves primrias de ambos os objetos relacionados N,N devero ser identificadas e, a seguir, um "objeto de interseo" dever ser criado. A chave primria do objeto de interseo ser a combinao ou concatenao das chaves primrias dos dois objetos originais. No exemplo ilustrado pela Fig. 23, em que um professor leciona vrias disciplinas (1,N) e uma disciplina pode ser ministrada por vrios professores. A nica linha do relacionamento muitos-para-muitos (N,N) pode ser considerada como sendo a combinao de dois relacionamentos um-para-muitos (1,N), ambos com um objeto de interseo.
Fig. 21 - Relacionamento muitos-para-muitos (N,N) entre DISCIPLINA e PROFESSOR
Para determinar os dados que devero estar contidos no objeto de interseo a ser criado, devemos analisar o relacionamento muitos-para-muitos entre DISCIPLINA e PROFESSOR fazendo as seguintes perguntas: Qual deve ser o objeto que possui uma chave primria que corresponda concatenao de um determinado "cdigo de disciplina" e de um determinado "nmero de professor"? Quais dados ou atributos dependem exclusivamente desta combinao? 51
Quais dados podem ser obtidos se soubermos que estamos lidando com uma determinada disciplina ministrada por um determinado professor? Ao tentarmos responder estas perguntas verificaremos que diferentes disciplinas podem ser ministradas por diferentes professores em determinados horrios e salas de aula ou, por outro lado, diferentes professores lecionam diferentes disciplinas em determinadas salas de aula e em determinados horrios. Portanto, como uma dada disciplina poder ser ministrada por diferentes professores em diferentes salas de aula e em diferentes horrios, podemos criar um objeto de interseo denominado TURMA. Desta forma, um determinado professor poder lecionar vrias disciplinas, cada uma em sua respectiva sala de aula e horrio; assim como cada disciplina poder ser ministrada por vrios professores, e para cada professor haver uma determinada sala de aula e horrio. A Fig. 24 ilustra o relacionamento muitos-para-muitos (N,N) entre DISCIPLINA e PROFESSOR resolvido por um relacionamento um-para-muitos (1,N) entre DISCIPLINA e TURMA e um relacionamento um-para-muitos (1,N) entre PROFESSOR e TURMA.
Fig. 22 - Relacionamento muitos-para-muitos resolvido
Neste caso, a chave primria de TURMA composta por duas chaves estrangeiras. Ou seja, para que uma TURMA seja identificada necessrio saber qual a disciplina e qual o professor. Como o "cdigo da disciplina" pertence a DISCIPLINA e o "nmero do professor" pertence a PROFESSOR, ambos so chaves estrangeiras em TURMA e concatenados formam a sua chave primria, pois a identificam. Conjuntos de Relacionamentos Consideremos agora um outro exemplo, o relacionamento entre VENDA e ITEM VENDIDO. Uma venda possui vrios itens ou produtos vendidos, mas um item ou produto vendido somente pode fazer parte de uma venda. O relacionamento entre VENDA e ITEM VENDIDO , portanto, um-para-muitos (1,N), como indica a Fig. 23.
52
Fig. 23 - Relacionamento entre VENDA e ITEM VENDIDO
Consideremos agora o lado dos produtos. Deve haver um relacionamento entre ITEM VENDIDO e PRODUTO. Como cada produto pode ser vendido vrias vezes, o relacionamento deve ser um-para-muitos (1,N), ou seja, um produto pode estar relacionado a vrios itens vendidos, como ilustra a Fig. 24.
Fig. 24 - Relacionamento entre ITEM VENDIDO e PRODUTO
Se agora considerarmos pelo lado dos clientes, verificaremos que para um mesmo cliente podero haver vrias vendas e, portanto, o "cdigo do cliente", identificador do cliente, dever ser parte do arquivo de dados VENDA, mas no parte de sua chave primria, pois apenas o "nmero da nota fiscal" por si s suficiente para identificar unicamente cada venda, como ilustrado na Fig. 25.
Fig. 25 - Relacionamento entre CLIENTE e VENDA
53
claro que se um cliente est relacionado a vrias vendas, cada venda est relacionada a vrios itens vendidos e cada item vendido a um produto, surge, ento, um conjunto de relacionamentos um-para-muitos, como ilustrado pela Fig. 26.
Fig. 26 - Relacionamento CLIENTE - VENDA - ITEM VENDIDO - PRODUTO
No necessrio incluir o "cdigo do cliente" tambm no arquivo ITEM VENDIDO, pois se desejarmos produzir um relatrio que informe a quais clientes foram vendidos quais produtos, possvel pesquisar todos os "nmeros de notas fiscais" no arquivo ITEM VENDIDO procura dos produtos do arquivo PRODUTO e depois, usando estes nmeros, pesquisar todos os clientes nos arquivos VENDA e CLIENTE. Entretanto, poderamos opcionalmente simplificar este processo e obter diretamente a informao desejada incluindo a chave estrangeira "cdigo do cliente" do arquivo CLIENTE no arquivo ITEM VENDIDO. Muitas vezes, no projeto da base de dados de um sistema aplicativo, podemos incluir diversos dados ou chaves estrangeiras nos arquivos relacionados, com o objetivo de simplificar a programao necessria para a obteno das informaes que devero ser fornecidas aos usurios. A anlise dos relacionamentos e chaves estrangeiras que devero ser includas em cada arquivo de dados deve ser feita nesta fase, com a ajuda do modelo de relacionamento de dados (RDM - Relational Data Model).
54
Variao no Tempo Para cada objeto de informao deve-se analisar se seus atributos (dados) variaro com o tempo. Para cada um destes dados deve-se verificar se ser necessrio armazenar o histrico dos valores que assumiu durante um determinado perodo de tempo ou de acordo com um determinado nmero de variaes. Por exemplo, no caso do custo de um determinado produto armazenado no estoque, seu preo poder variar no decorrer do tempo. De acordo com as necessidades dos usurios do sistema devemos analisar se ser suficiente apenas guardar o preo atual ou se devemos manter disponvel o histrico do preo de cada produto dentro de um determinado perodo. A quantidade do produto no estoque tambm ser alterada ao longo do tempo. Devemos analisar se ser necessrio manter a movimentao do estoque para cada produto, ou seja, entradas (compras) e sadas (vendas), ou apenas suficiente manter o saldo atual. Alm disso, devemos decidir se produtos descontinuados sero mantidos nos registros dos arquivos de dados que comporo o sistema. Da mesma forma que no exemplo com produtos em estoque, diversos outros objetos de informao, como funcionrios, vendas, compras etc., devero ser analisados para se decidir se devero ser mantidos registros histricos. Toda vez que for tomada uma deciso de se armazenar um dado histrico de um objeto de informao determina-se implicitamente um relacionamento um-para-muitos, com um arquivo de dados dependente, contendo a data de alterao, o valor do dado a partir desta data e outros dados que forem necessrios para caracterizar a alterao ocorrida. Uma vez criado esse arquivo histrico dependente, deve-se decidir tambm se o valor atual do dado, por exemplo, saldo atual do produto no estoque, deve ser armazenado no arquivo principal dos produtos, ou se ele deve ser calculado (derivado) a partir do arquivo histrico, apenas quando for necessrio. Na verdade, esta deciso tambm envolve uma questo de desempenho do sistema, pois o clculo do valor atual sempre consumir algum tempo. Assim como na anlise da necessidade de se armazenar dados histricos de determinadas entidades, como os produtos, devemos considerar tambm por quanto tempo os registros de eventos, como vendas ou compras, precisam ser mantidos em disponibilidade no sistema. Cada registro de evento deve possuir uma periodicidade fixa no sistema para o seu armazenamento no arquivo de dados, como por exemplo um ms, seis meses ou um ano. Aps este perodo, o registro do evento e todos os outros a ele relacionados, devem ser transferidos para um ou mais arquivos histricos, destinados ao armazenamento permanente deste tipo de evento. O arquivo original poder ser, ento, totalmente limpo para iniciar um novo perodo. Posteriormente, os dados histricos devero poder ser recuperados dos arquivos histricos caso sejam necessrios.
55
Tipos de Objeto Muitas vezes, diversos objetos de informao identificados pela anlise de entidades e relacionamentos so, na verdade, tipos diferentes do mesmo objeto. Podemos citar, por exemplo, com respeito entidade empregado, os ativos, os ex-empregados e os aposentados; ou os pagos por hora, os pagos por semana e os pagos por ms. So todos subtipos ou classificaes diferentes da mesma entidade empregado. A questo crucial a similaridade ou a diferena entre os dados que descrevem os diversos subtipos ou subgrupos de empregados. Poder haver apenas um arquivo de dados para armazenar todos os tipos, com um determinado dado (cdigo) que os distinga, ou poder haver um arquivo de dados para cada subtipo. Esta deciso requer um estudo detalhado do sistema e do software atravs do qual ele ser implementado, com uma avaliao das vantagens e das desvantagens em cada caso. Um outro exemplo pode ser considerado tomando-se o evento venda. Podemos ter vendas a vista, vendas a prazo, vendas atravs de carto de crdito e vendas com cheques prdatados. Todas elas tm uma data, um cliente e um valor total em comum. O tipo de venda pode ser armazenado num dado denominado "especificao", contendo cdigos que identifiquem o tipo da venda efetuada: VI a vista, CC carto de crdito, CP cheque pr e VP a prazo. No modelo relacional de dados os subtipos ou especificaes existentes dentro de uma entidade ou evento devem ser representados como ilustra a Fig. 27, na qual esto destacados os diferentes subtipos que podem existir. Note que para cada subtipo de venda podem existir outros arquivos relacionados ao arquivo de vendas, para o armazenamento dos dados especficos destes subtipos.
56
Fig. 27 - Representao de subtipos de entidades
O Modelo Relacional de Dados (RDM - Relational Data Model) O resultado final da anlise de entidades e relacionamentos um diagrama em que cada retngulo representa um arquivo na base de dados do sistema. Sua finalidade esclarecer a natureza dos arquivos de dados do BPM. Todos os relacionamentos um-para-um (1,1) devem ter sido examinados e determinados como no sendo subdivisveis. As chaves estrangeiras que estabelecero cada relacionamento tambm j devero ter sido definidas. Finalmente, nenhum relacionamento muitos-para-muitos (N,N) deve aparecer explicitamente, pois todos j devero ter sido resolvidos em relacionamentos um-paramuitos (1,N) atravs da utilizao de arquivos de interseo. Na pgina seguinte, a Fig. 28 apresenta o modelo relacional de dados (RDM) de um sistema para controle do aluguel de filmes de vdeo locadoras.
57
Modelagem dos Dados

Introduo
Aps a construo do RDM, deve ser definido o contedo exato de cada arquivo de dados que compor a base de dados do sistema. Devero ser detalhadas as caractersticas de todos os dados que sero armazenados em cada arquivo que descreve os atributos das entidades e eventos definidos pelo modelo relacional de dados. Para detalhar os dados que devero estar contidos nos arquivos de dados ou tabelas do sistema, inicialmente devemos considerar todas as entradas e sadas sobre as quais se tenha o mximo de informaes. Trabalhamos para frente a partir das entradas e para trs a partir das sadas, para definir os dados de cada arquivo. O objetivo obter o menor nmero possvel de dados em cada arquivo, suficiente para derivar as sadas (relatrios ou consultas na tela) e capturar a essncia das entradas. Entretanto, utilizando apenas esta tcnica, estaremos correndo o risco de no descobrir todos os dados necessrios, principalmente por ser muito difcil para os usurios de um sistema imaginarem, com antecipao, toda a sada futura possvel e toda a entrada necessria. Por esse motivo, aps a definio inicial dos dados de cada arquivo, a partir das entradas e sadas previstas, devemos efetivamente visitar os locais nos quais os usurios efetuam suas operaes para observ-las e examinar todas as entidades (como produtos) e todos os eventos (como vendas) a elas relacionados. Com esta visita poderemos verificar todos os atributos que estas entidades e eventos possuem e que sero de interesse para o fornecimento de informaes, completando o que eventualmente tiver sido esquecido ou no percebido pelos usurios na definio inicial.
58
59
Normalmente, toda entidade, como por exemplo um produto, possui um identificador nico e exclusivo, como um cdigo; alm disso, preciso armazenar o seu nome ou descrio, juntamente com a quantidade, o custo e o preo de venda. Produtos grandes podem possuir tambm uma localizao, um volume e um peso; enquanto que produtos pequenos podero estar acondicionados em embalagens com um determinado nmero de unidades. Por outro lado, todo evento tambm dever receber um identificador exclusivo e nico, como um nmero de documento, quase sempre tem uma data de ocorrncia, e muitas vezes uma ou mais entidades relacionadas, como a venda de produtos a um cliente. Finalmente, aps a verificao dos dados que descrevem todas as entidades e eventos de interesse do sistema in loco, voc deve se perguntar: "Se eu dirigisse este negcio, o que gostaria que fosse armazenado no sistema?" Certamente, quanto mais voc conhecer o negcio e compreender os objetivos dos usurios em requisitar o sistema, tanto melhor poder responder esta pergunta. Contudo, voc no dever tentar dizer a um empresrio como a empresa dele deve ser administrada, mas poder certamente fazer sugestes. Em geral, mais fcil oferecer uma lista de sugestes de dados ao usurio e solicitar que ele elimine e/ou acrescente itens na lista. Deste modo, voc estar dizendo ao usurio: "Segundo meus limitados conhecimentos do seu negcio, parece que seria til ter essas informaes armazenadas no sistema. H alguma coisa que eu esqueci? E, considerando o custo de coletar e armazenar informaes, h alguma coisa na lista que pode ser omitida sem lhe fazer falta no futuro?" Ao formular estas perguntas, voc estar efetivamente envolvendo o usurio no projeto do sistema, fazendo com que ele se sinta comprometido com sua definio e, portanto, sendo mais cuidadoso e responsvel ao respond-las. A partir dos resultados obtidos voc poder produzir uma definio preliminar do contedo de cada arquivo de dados que descreve uma entidade ou um evento de interesse para o sistema e, obviamente, para a organizao.
Nome dos Dados
Cada dado deve possuir um nome exclusivo, e ser to significativo quanto possvel, sem a inconvenincia de ser longo. H muitas formas e convenes que foram propostas para dar nomes aos dados, voc poder utilizar uma delas ou criar a sua prpria. Porm, definindose por uma, procure mant-la em todos os seus sistemas. Recomendamos que cada dado tenha uma descrio resumida, um nome completo e um nome abreviado ou codificado. A descrio dever explicar inteiramente a natureza do dado e ser utilizada para descrever o dado num dicionrio de dados que far parte da documentao do sistema. O nome completo dever ser o nome do dado que ser apresentado ao usurio na tela ou num relatrio, identificando o dado. Finalmente, o nome abreviado dever ser o nome-cdigo do dado dentro do sistema, ou seja, o nome do dado
60
dentro dos arquivos de dados (nome do campo) e dentro dos programas que comporo o sistema. Por exemplo:
Nome Completo Cdigo do produto Nome do produto Quantidade pedida Nome Abreviado Codprod Nomprod Qtdped Descrio Cdigo de produto. identificao do
Nome que identifica o produto. Quantidade de um produto que foi pedida por um cliente.
Devido limitao de 10 caracteres para identificar nomes de campos nos arquivos de dados de alguns softwares e para economizar digitao e simplificar a programao, recomendamos que os nomes abreviados dos dados tenham no mximo 10 posies. Alm disso, pode ser utilizado o sublinhado ( _ ) para separar nomes compostos, pois os nomes abreviados no podero conter espaos em branco. Por exemplo: cod_prod, cod_cli, num_vend etc.
Sinnimos
Muitas vezes, nomes diferentes so utilizados para identificar uma mesma entidade ou evento em locais diferentes de uma organizao. Os termos "empregado", "funcionrio" ou "servidor" podero ser utilizados em diferentes reas para significar uma pessoa que trabalha na organizao. Eles so sinnimos e, embora seja melhor evitar a utilizao de sinnimos num sistema, eles podem ser tratados escolhendo-se um dos nomes como sendo o principal e descrevendo os demais como sinnimos do nome principal. O mesmo ocorre com os nomes de dados, por exemplo, "estado" e "uf" ou "cidade" e "municpio", ou ainda, em alguns casos, "custo" e "preo".
Homnimos
A situao inversa tambm existe, ou seja, um determinado nome poder ter significados diferentes para entidades ou eventos distintos em diversas reas da organizao. Por exemplo, o nome "preo", poder significar o "preo unitrio de venda" para o departamento de vendas, o "preo unitrio de custo" para o departamento de compras e o "preo total de venda ou de compra" para o departamento de contabilidade. Deve ficar suficientemente claro, dentro do contexto no qual o homnimo utilizado, que significado, dentre os diversos possveis, ele ter. Se no se conseguir determinar com clareza um significado nico, ento cada dado dever receber um nome diferente.
Domnio
O domnio de um dado o conjunto de valores vlidos para ser seu contedo. Assim, o domnio de uma data pode ser qualquer data vlida posterior a 01/01/1900; o domnio do preo de um produto pode ser um valor entre R$ 100,00 e R$ 2.000,00; o domnio da 61
sigla dos estados do Brasil um par de letras contidas num conjunto bem definido; e assim por diante. Se for possvel determinar o domnio de um dado, voc poder definir critrios de validao para determinar os valores aceitveis durante a entrada ou edio de dados.
Caractersticas dos Dados
Alm do nome, da descrio, do nome abreviado e do domnio, outras caractersticas relativas a cada elemento de dado devem ser definidas para descrever completamente o contedo de um arquivo de dados: 1. Tipo de dado: refere-se ao contedo do dado, podendo ser normalmente, numrico (NMERO, INTEIRO ou FLUTUANTE), cadeia de caracteres curta (TEXTO), data (DATA), lgico (LOGICO) ou cadeia de caracteres longa (MEMO). Dependendo da ferramenta de software que estiver sendo utilizada para implementar o sistema, estes tipos podero variar. 2. Comprimento do dado: refere-se ao tamanho ou nmero mximo de posies que poder assumir o valor ou contedo de cada dado. Normalmente, dados do tipo numrico podero assumir at 19 posies, com at 18 casas decimais; dados do tipo caractere curto podero assumir at 256 posies; dados do tipo data assumiro automaticamente 8 posies; dados do tipo lgico apenas uma posio e dados tipo memo ou caractere longo no precisam ter o comprimento pr-definido, podendo assumir at 65.535 posies. Recomendamos que, em vez de solicitar que os usurios especifiquem o comprimento dos dados, voc pea exemplos dos valores de dados que os usurios desejam armazenar nos arquivos e, a partir deles, especifique de forma equilibrada (como uma mdia entre os maiores e os menores) os comprimentos ideais. 3. Formato do dado: refere-se forma com que os dados devero ser editados ou apresentados, definindo as posies de determinados smbolos, como pontinhos, tracinhos e barras, geralmente contidos em cdigos, ou a presena de pontos separando os milhares em valores numricos. O formato do dado geralmente definido pela clusula PICTURE ou MSCARA dos comandos e funes do software utilizado para o desenvolvimento do sistema. Para definir o formato dos dados so utilizadas mscaras de formatao, nas quais normalmente o dgito "9" representa posies onde somente devem ser aceitos dgitos numricos; a letra "A", posies onde devem ser aceitas letras alfabticas; e a letra "X", posies onde podem ser aceitos quaisquer valores de dados. Por exemplo, o formato do dado CPF deve ser assim representado como "999.999.999/99", e o formato do dado salrio deve ser representado como "999.999,99". 4. Tipo de domnio: especifica se os valores de dados aceitveis so definidos por estarem numa lista (domnio discreto, como a sigla dos estados), ou por satisfazer determinada regra (domnio contnuo, como faixa de valores numricos, letras maisculas etc.). Para um domnio discreto, os valores aceitveis devem ser relacionados numa tabela conveniente, junto com o significado de cada valor, pois os 62
significados sero utilizados pelo sistema. Por exemplo, o dado estado civil poder possuir o seguinte domnio discreto: S = solteiro, C = casado, V = vivo, P = separado, J = separado judicialmente e O = outros. Para um domnio contnuo, o critrio de validao deve ser especificado, relacionando, quando relevante, os valores mximos e os mnimos aceitveis. Em qualquer caso, deve ser especificado se o valor vazio ou nulo, ou seja, ausncia de valor, pode fazer parte do domnio do dado. Por exemplo, dados chave no podem aceitar o valor nulo. 5. Regra de Validao: especifica uma regra que deve ser verificada para que os dados sejam considerados vlidos. Uma regra de validao pode ser uma expresso matemtica, obrigando um dado numrico a se situar dentro de uma determinada faixa de valores vlidos, ou uma expresso qualquer valide os dados digitados pelo usurio, comparando-o inclusive com outros dados j digitados. Quando a regra validar o dado, o mesmo ser aceito e armazenado no arquivo de dados; em caso contrrio o sistema dever apresentar uma mensagem ao usurio informando que o dado est incorreto, solicitando a digitao de dados vlidos. 6. Origem do dado: querendo dizer se os valores de dados so capturados fora do sistema (como uma entrada de dados atravs de digitao), se so originados dentro do sistema (como identificadores de transaes, definidos pelo prprio sistema) ou se so derivados de outros elementos de dados (como custo total = custo unitrio x quantidade, calculados pelo sistema). Em cada caso ser necessrio especificar como o dado obtido ou gerado, ou seja, a partir de que documento, de que transao ou de que clculo o valor do dado obtido. 7. Responsabilidade pelo dado: revela a pessoa ou a unidade da empresa responsveis pelo dado, ou seja, que tenham a autoridade final pela correta maneira como o dado deve ser inserido e atualizado no sistema. Por exemplo, o Gerente de Pessoal responsvel pelo dado salrio, uma vez que somente ele pode autorizar uma alterao do valor do salrio de qualquer funcionrio.
Exemplo: ESTADO CIVIL
Nome do Dado: Descrio: Nome Abreviado: Tipo: Comprimento: Formato: Domnio: Origem: Responsabilidade: Estado Civil. Estado civil do funcionrio para efeitos legais. EST_CIV Caractere (C ou CHAR) 1 posio Uma letra maiscula: A S = Solteiro, C = Casado, V = Vivo, J = Separado judicialmente, O = outros. Entrada de dados atravs da ficha cadastral de funcionrio. Chefe de pessoal.
63
Dados-chave Tendo j definido os dados que constituiro os campos de um arquivo de dados, conforme o RDM um ou mais dados devero ser escolhidos para funcionar como chave primria ou identificadora de registros, de modo que sabendo o valor da chave, voc poder acessar um determinado registro do arquivo, ou seja, a chave que identifica cada registro armazenado num arquivo de dados. Todo arquivo de dados dever ter pelo menos um campo definido como chave primria ou identificadora. Assim, o valor contido numa chave primria dever ser exclusivo, ou seja, nico por registro do arquivo e, uma vez designado, nunca dever ser alterado. Alm disso, um dado que faa parte de uma chave (primria ou estrangeira) nunca dever possuir um valor ausente ou nulo, pois perder sua utilidade, tanto como identificador de registros como apontador de relacionamentos entre arquivos de dados. Se uma chave primria no existir naturalmente entre os dados que descrevem as entidades e os eventos de interesse do sistema, uma chave identificadora exclusiva dever ser criada, como cdigo do produto, nmero do funcionrio, nmero do pedido etc. Esta chave primria poder ser arbitrria, designada possivelmente pelo prprio sistema, incrementando um nmero para cada novo registro, com o nico objetivo de poder acess-los inequivocamente. Em qualquer caso, a chave primria assim criada dever ser concisa para facilitar a digitao sem erros e o acesso inequvoco aos dados de cada registro. Normalmente, a chave primria determinar os campos que sero utilizados para a criao do ndice primrio de acesso ao arquivo de dados, permitindo, desta forma, a localizao instantnea dos registros que as possuem. Estruturas Embutidas Muitas vezes interessante subdividir um dado chave em partes que possuam significados especiais. Por exemplo, o cdigo de um produto pode ser formado por trs partes, no formato 99.99.999, cada uma com um significado diferente. Desta forma, como ilustra a tabela apresentada a seguir, o cdigo do Leite tipo A 02.01.001, do Leite tipo B 02.01.002, e assim por diante. Com esta estrutura de classificao embutida no cdigo dos produtos torna-se mais simples identificar os produtos de um determinado tipo ou de uma determinada categoria, facilitando a gerao de relatrios e informaes sobre grupos especficos de produtos. Um exemplo clssico de estruturas embutidas em dados chave o das contas contbeis. Em um sistema de contabilidade, as contas so classificadas por tipo em ativo, passivo, receita e despesa. Dentro de cada tipo podem ser abertas contas, subcontas e subsubcontas, formando uma hierarquia de totalizao. Desta forma, o processamento do balano e do demonstrativo de resultados fica facilitado, ou seja, as subsubcontas so
64
totalizadas nas subcontas, as subcontas nas contas e por fim, as contas nos respectivos totais de ativo, passivo, receita e despesa. Sempre que as entidades ou eventos de interesse do sistema puderem ser classificados, conveniente utilizar estruturas hierrquicas embutidas nos dados chave, pois o acesso e o processamento dos registros ser facilitado. Entretanto, a construo das estruturas embutidas deve ser muito bem estudada, para que a necessidade de classificao seja esgotada, isto , cada entidade ou evento deve receber o cdigo adequado, de acordo com suas caractersticas. Se um deles no puder ser adequadamente classificado dentro da estrutura prevista, todos os cdigos eventualmente j atribudos devero ser revistos e a estrutura de classificao alterada, o que representar um trabalho considervel.
99 = Tipo de produto: 01 02 03 04 01.99 = Categoria: 01 02 03 04 02.99 = Categoria: 01 02 03 04 01.01.999 = Produto: 001 002 003 004 02.01.999 = Produto: 001 002 003 004 005 = = = = = = = = = = = = = = = = = = = = = Bebidas Laticnios Farinceos etc. Alcolicas No-alcolicas Dietticas etc. Leite Queijo Iogurte etc. Whisky Vodka Pinga etc. Leite Tipo A Leite Tipo B Leite Tipo C Leite Desnatado etc.
65
Mltiplas Chaves Em algumas situaes, h mais de um campo ou conjunto de campos que sero utilizados para identificar exclusivamente cada registro num arquivo de dados. Neste caso, deveremos certificar-nos de que todas os campos que formaro a chave primria sejam no nulos, no sejam alterados e que sua combinao seja exclusiva para identificar cada registro inequivocamente. Em outras situaes, poder existir mais de um campo que possa ser utilizado como chave identificadora de registros. Por exemplo, o nmero do empregado, seu CIC e seu RG podero ser utilizados para identific-lo. Neste caso, para decidir qual dos campos ser a chave primria deveremos verificar se h garantia de exclusividade, se os dados no sero alterados e se no existiro dados nulos. O campo que melhor satisfizer estas caractersticas deve ser escolhido como chave primria.
Normalizao
Introduo Um sistema de informao utiliza um conjunto de arquivos de dados relacionados, conforme definido pelo RDM e pela modelagem de dados, nos quais so armazenados os dados que descrevem as entidades e eventos sobre os quais se deseja obter informao. Podemos definir uma base de dados ou banco de dados como sendo este conjunto de arquivos de dados vinculados ou relacionados, dentro de um determinado contexto, definido pelos objetivos do sistema em questo. Definidos os arquivos e os respectivos dados que formaro a base de dados do sistema, o prximo passo do projeto simplific-los para adequ-los ao processamento do computador, removendo dados redundantes e grupos repetitivos. Este processo de simplificao de arquivos de dados que compem uma base de dados denominado normalizao. Os conceitos e as tcnicas de normalizao de arquivos de dados foram desenvolvidos pelo Dr. E. F. Codd da IBM e sua equipe, quando pesquisavam a matemtica de conjuntos. No conjunto matemtico, nenhuma duplicata de qualquer objeto permitida. Como um arquivo um conjunto de registros, na teoria nenhum registro, num arquivo de dados, pode ser uma duplicata de qualquer outro. Alm disso, de acordo com a teoria dos conjuntos, foram estabelecidos cinco tipos de arquivos normalizados, denominados, em ordem crescente de simplicidade: primeira forma normal (1FN), segunda forma normal (2FN) e terceira forma normal (3FN), quarta forma normal (4FN) e quinta forma normal (5FN).
66
Atravs da normalizao, os arquivos de dados tornam-se mais adequados para o armazenamento e atualizao de dados, evitando-se redundncias e inconsistncias na base de dados. O processo de normalizao consiste, basicamente, na aplicao de um conjunto de regras para definir adequadamente os dados ou campos que comporo os arquivos de dados. Essas regras visam: Minimizar redundncias; Eliminar anomalias de atualizao; Prover o melhor caminho de acesso a qualquer dado; Assegurar resistncia a manutenes no modelo de dados; Evitar dados no identificveis atravs de definio rigorosa de identificadores e relacionamentos. Definiremos a seguir as trs primeiras formas normais e discutiremos a maneira de simplificar os arquivos de dados at a terceira forma normal. Em geral, apenas as trs primeiras regras bsicas de normalizao so suficientes para resolver a grande maioria dos casos. Poderamos resumir estas trs formas normais mais utilizadas da seguinte forma: 1. Eliminar campos repetitivos; 2. Eliminar dados redundantes; 3. Eliminar atributos no dependentes. Primeira Forma Normal (1FN) Refere-se a qualquer arquivo que possua apenas um valor por campo, ou interseo linha/coluna. O relacionamento entre a chave primria de um arquivo e cada um dos outros campos (dados ou colunas) deve ser de um-para-um (nesta direo). Cada um dos campos que no fazem parte da chave primria so chamados "funcionalmente dependentes" desta chave. Arquivos de dados que obedecem esta regra esto na Primeira Forma Normal (1FN). De uma maneira prtica, devemos remover grupos repetidos de dados, at que cada dado tenha uma chave primria para cada ocorrncia. O arquivo de dados exemplificado a seguir no est sob qualquer forma normal; entre outras coisas, h mais de um valor ou supermercado no campo loja.
67
Produtos em Estoque No Normalizado

Produto Arroz Feijo Farinha Acar S, Eldorado, Carrefour, Jumbo S, Carrefour, Jumbo, Minibox Eldorado, Carrefour, Jumbo Carrefour, Jumbo, Minibox Loja
Como pode ser percebido, no campo loja existem vrios valores de dados (grupos repetidos). Atravs deste arquivo podemos obter a informao de que existe, por exemplo, arroz nos supermercados S, Eldorado, Carrefour e Jumbo. Entretanto, como poderemos saber a quantidade de arroz existente em cada um? De acordo com a primeira forma normal este arquivo deve ser revisado para que sejam eliminados os grupos repetidos, ou seja, no campo loja deve haver o nome de apenas um supermercado. Isso implicar, a criao de um nmero maior de linhas ou registros no arquivo, pois dever haver uma linha para cada produto em cada loja. Contudo, a partir da, poderemos facilmente registrar a quantidade existente de cada produto em cada loja. Aps a aplicao da primeira regra de normalizao, o arquivo de dados dos produtos em estoque assume a seguinte estrutura de dados:
Produtos em Estoque na 1FN
Produto Arroz Arroz Arroz Arroz Feijo Feijo Feijo Feijo Farinha Farinha Farinha Acar Acar Acar S Eldorado Jumbo Carrefour S Carrefour Jumbo Minibox Eldorado Carrefour Jumbo Carrefour Jumbo Minibox Loja Telefone 213-0909 814-0845 453-1111 864-1212 213-0909 814-0845 453-1111 284-5967 814-0845 864-1212 453-1111 814-0845 453-1111 284-5967 Quantidade. 200 500 700 1000 300 500 200 800 400 600 100 1100 900 1200 Preo 10,00 9,00 11,00 8,00 13,00 12,00 14,00 11,00 8,00 9,00 7,00 4,00 5,00 3,00 Total 2.000,00 4.500,00 7.700,00 8.000,00 3.900,00 6.000,00 2.800,00 8.800,00 3.200,00 5.400,00 700,00 4.400,00 4.500,00 3.600,00
68
Segunda Forma Normal (2FN) Um arquivo de dados na primeira forma normal tambm estar na segunda forma normal se todo campo no-chave depender totalidade da chave primria. Para testar se um arquivo de dados est na segunda forma normal devemos fazer inicialmente as seguintes perguntas: 1. Qual o campo ou conjunto de campos que constitui a chave primria do arquivo? Se a chave primria for concatenada, isto , formada por mais de um campo, perguntamos tambm: 2. H qualquer campo no-chave que dependa de apenas parte da chave primria? No arquivo do exemplo anterior, o produto, por si s no suficiente para identificar inequivocamente um determinado registro, pois vrios registros possuem o mesmo produto. Para obtermos uma chave primria exclusiva devemos concatenar produto com loja, pois no h nenhuma chave "produto + loja" duplicada. Neste caso, como a chave concatenada, devemos ainda fazer a segunda pergunta para cada campo no-chave: 1. A quantidade em estoque depende apenas de parte da chave? A resposta no, preciso conhecer tanto o produto como a loja para se obter a quantidade. 2. O preo depende apenas de parte da chave? A resposta tambm no, preciso conhecer tanto o produto como a loja para se obter o preo. 3. O telefone da loja depende apenas de parte da chave? Neste caso a resposta sim, pois se voc conhecer a loja tambm poder saber qual o seu telefone, independentemente do produto. Portanto, o arquivo exemplificado anteriormente no est na segunda forma normal, pois ele no passou pelo teste. Quando um arquivo de dados no est na segunda forma normal, a base de dados no estar correta pelas seguintes razes: 1. O arquivo de dados ocupar mais espao no disco do que seria necessrio, pois o nmero do telefone se repete para cada produto armazenado no mesmo arquivo; 2. Se uma loja mudar de nmero de telefone, todos os registros de produtos para aquela loja devero ter o campo telefone alterado; 3. Se ocorrer algum problema com o processo de atualizao dos dados, uma mesma loja poder aparecer com nmeros de telefones diferentes, dependendo de qual registro seja acessado posteriormente, ou seja, a integridade da base de dados estar perdida; 4. Quando uma loja possuir um nico produto e seu registro for eliminado (por que acabou o estoque), tambm ser eliminado o telefone da loja, pois poder no haver outro lugar na base de dados que o armazene. Para evitar estes problemas, o arquivo anterior dever ser dividido em dois, como ilustrado a seguir. 69

Produto Arroz Arroz Arroz Arroz Feijo Feijo Feijo Feijo Farinha Farinha Farinha Acar Acar Acar S Eldorado Jumbo Carrefour S Carrefour Jumbo Minibox Eldorado Carrefour Jumbo Carrefour Jumbo Minibox Loja Quantidade 200 500 700 1000 300 500 200 800 400 600 100 1100 900 1200 Preo 10,00 9,00 11,00 8,00 13,00 12,00 14,00 11,00 8,00 9,00 7,00 4,00 5,00 3,00 Total 2.000,00 4.500,00 7.700,00 8.000,00 3.900,00 6.000,00 2.800,00 8.800,00 3.200,00 5.400,00 700,00 4.400,00 4.500,00 3.600,00
Lojas
Loja S Eldorado Jumbo Carrefour Minibox Rua Inflao, 100 Rua Carestia, 50 Rua Salrio Mnimo, 10 Av. Preo Alto, 1000 Rua Novo Pacote, 5 Endereo Telefone 213-0909 814-0845 453-1111 814-0845 284-5967
Agora os dois arquivos esto na segunda forma normal. O arquivo de produtos em estoque est na segunda forma normal porque os campos no-chave (quantidade, preo e valor total) so dependentes de toda chave primria concatenada produto+loja e de nada mais. O segundo arquivo, lojas, tambm est na segunda forma normal porque ele no possui uma chave concatenada e, portanto, uma coluna no-chave como endereo ou telefone naturalmente ser dependente da totalidade do nico campo chave, que a loja. Analisando sob outro ngulo, fcil perceber que o arquivo anterior, apesar de estar na primeira forma normal, contm dados descrevendo duas coisas distintas: produtos e lojas. Como regra geral e importante, um arquivo de dados numa base de dados deve armazenar 70
dados que descrevam apenas uma entidade ou evento. Portanto, um arquivo de dados, para estar na segunda forma normal deve conter dados apenas sobre um nico objeto de informao ou uma nica classe de objetos. Neste nosso exemplo, o primeiro arquivo agora contm apenas dados sobre produtos em estoque e o segundo sobre lojas. Terceira Forma Normal (3FN) Um arquivo na segunda forma normal tambm estar na terceira forma normal se nenhum campo no-chave depender de qualquer outro campo no-chave. Para verificar se um arquivo na segunda forma normal tambm est na terceira forma normal devemos perguntar: algum campo no-chave dependente de qualquer outro campo no-chave? O arquivo dos produtos em estoque possui trs campos (ou colunas) no-chave: quantidade, preo e valor total. Se soubermos a quantidade em estoque e o preo, saberemos o valor total em estoque. Portanto, o campo "valor total" dependente de dois campos no-chave, pois pode ser obtido a partir da quantidade multiplicada pelo preo. Conclumos, ento, que arquivo de produtos em estoque no est sob a terceira forma normal. Se o campo "valor total" for eliminado, o arquivo de produtos em estoque passa a estar na terceira forma normal, ocupando menos espao no disco, sem qualquer perda de informao.
Produto Arroz Arroz Arroz Arroz Feijo Feijo Feijo Feijo Farinha Farinha Farinha Acar Acar Acar S Eldorado Jumbo Carrefour S Carrefour Jumbo Minibox Eldorado Carrefour Jumbo Carrefour Jumbo Minibox Loja 200 500 700 1000 300 500 200 800 400 600 100 1100 900 1200 Quantidade 10,00 9,00 11,00 8,00 13,00 12,00 14,00 11,00 8,00 9,00 7,00 4,00 5,00 3,00 Preo
71
Resultado da Normalizao de Arquivos Apesar de existirem as simplificaes da quarta e da quinta forma normal, que ainda podero ser feitas em arquivos de dados, via de regra, os arquivos que estiverem na terceira forma normal no contm redundncias, so simples de serem compreendidos, simples de serem atualizados e seus dados podem ser facilmente recuperados. J esto, portanto, numa forma adequada para serem implementados num sistema de informao. Ao adquirir experincia no desenvolvimento de sistemas, a simplificao de arquivos at a terceira forma normal se tornar praticamente automtica e poder j ser feita durante a elaborao do RDM. Contudo, a simplificao dos dados tambm requer conhecimento da empresa, dos mtodos e regras por ela utilizados, os quais determinam os relacionamentos entre os dados, e as possveis alteraes que esses relacionamentos possam sofrer. O processo de normalizao pode resultar em um grande nmero de arquivos de dados. Entretanto, uma boa parte dos arquivos resultantes possuir apenas dois campos: um cdigo de algum tipo, que ser a chave primria, e o significado correspondente a cada cdigo. Considere o arquivo de turmas ilustrado a seguir. Este arquivo no est na terceira forma normal porque h uma dependncia entre campos no-chave: se voc souber o cdigo da disciplina, voc saber o seu nome, e se voc souber o nmero do professor, tambm poder obter o seu nome. Portanto, este arquivo deve ser decomposto em trs outros arquivos que so a seguir apresentados.
Arquivo das Turmas no Normalizado
Sem. 1/90 2/90 1/90 1/91 2/91 1/91 2/91 2/91 Matria EAD-151 EAD-274 EAD-456 EAD-151 EAD-274 EAD-456 EAD-556 EAD-455 Nome Proc.de Dados Anlise de Sistemas Sistemas Especialistas Proc.de Dados Anlise de Sistemas Sistemas Especialistas Inteligncia Artificial Bancos de Dados Sala 2 4 9 3 6 7 1 5 Hora 9:00 7:30 7:30 7:30 8:30 8:30 9:00 7:30 Dias 3as e 6as Sbado 4as e 6as 2as e 4as Sexta 3as e 6as Sbado 3as e 5as Prof. 123 345 234 023 145 234 001 354 Nome Vidal Hiroo Ronaldo Alosio Nicolau Ronaldo Einsten Hiroo
Arquivos com apenas dois campos, como professores e disciplinas, so tabelas de interpretao ou traduo de cdigos. Eles contm, em geral, dados relativamente estveis, isto , que raramente so alterados.
72
Arquivo de Turmas Normalizado

Sem. 1/90 2/90 1/90 1/91 2/91 1/91 2/91 2/91 Disciplina EAD-151 EAD-274 EAD-456 EAD-151 EAD-274 EAD-456 EAD-556 EAD-455 Sala 2 4 9 3 6 7 1 5 Horrio 9:00 7:30 7:30 7:30 8:30 8:30 9:00 7:30 Dias 3as e 6as Sbado 4as e 6as 2as e 4as Sexta 3as e 6as Sbado 3as e 5as Professor 123 345 234 123 345 234 001 354
Arquivo de Disciplinas
Disciplina EAD-151 EAD-274 EAD-456 EAD-556 EAD-455 Nome Processamento de Dados Anlise de Sistemas Sistemas Especialistas Inteligncia Artificial Bancos de Dados
Arquivo de Professores
Nmero 123 345 234 145 023 001 Nome Antonio Geraldo Vidal Hiroo Takaoka Ronaldo Zwicker Nicolau Reinhard Alosio Pinto Alves Albert Einsten da Silva
Reconstruo do BPM e do RDM

Aps os dados terem sido definidos e o contedo dos arquivos de dados ter sido simplificado at pelo menos a terceira forma normal, o modelo de processos do negcio (BPM) e o modelo relacional de dados (RDM) do sistema provavelmente devero precisar ser reconstrudos ou pelo menos revisados, pois novos arquivos apareceram, novos fluxos e relacionamentos sero necessrios e at mesmo processos. 73
Aps a normalizao, embora cada arquivo possa ser representado no BPM, haver mais clareza se: 1. Forem omitidas as tabelas de interpretao de cdigos; 2. Forem agrupados num nico smbolo de arquivo de dados todos os arquivos e tabelas de interpretao de cdigos que normalmente so acessados juntos por descreverem um mesmo objeto, como VENDAS e ITENS VENDIDOS ou COMPRAS e ITENS COMPRADOS. No RDM, caso o sistema seja muito abrangente e possua muitos arquivos de dados, as tabelas de interpretao de cdigos tambm podero ser omitidas.
Desempenho do Sistema
Utilizao de ndices A criao de um arquivo de ndice acelera a recuperao dos dados do arquivo pois este especifica onde, no disco, os registros desejados devem ser encontrados. Assim, em princpio, qualquer registro de um arquivo de dados indexado pode ser encontrado por apenas dois movimentos da cabea de leitura disco (um para o ndice, e outro para o localizao do registro no arquivo), em vez de uma quantidade enorme de movimentos para pesquisar o arquivo inteiro, registro por registro. Entretanto, esta velocidade de recuperao de dados em arquivos indexados possui dois custos: 1. O espao em disco ocupado pelo arquivo de ndice; 2. O tempo adicional necessrio para cada atualizao de dados, pois o arquivo de ndice precisa ser atualizado em conjunto com o arquivo de dados. Se houver espao disponvel em disco, o espao adicional ocupado pelos arquivos de ndice poder no ser problema, e a melhoria de desempenho ser compensadora. Da mesma forma, gastar um pouquinho mais de tempo para atualizar um arquivo devido atualizao simultnea dos arquivos de ndice associados, em geral, no um fator crtico para a maioria das aplicaes. Entretanto, quanto mais arquivos de ndices forem criados, mais lenta ser a atualizao dos dados e mais espao em disco ser consumido. Portanto, como regra geral, voc deve criar o mnimo de ndices necessrios para fornecer um desempenho adequado: 1. Para a chave identificadora ou primria de cada arquivo de dados deve ser criado um arquivo de ndice exclusivo. Isto deve ser feito de qualquer modo para garantir a unicidade do valor da chave (registros no duplicados), mas tambm importante para o desempenho, pois a chave ser o argumento de pesquisa mais freqentemente utilizado para a atualizao e recuperao de registros e provavelmente a chave 74
tambm ser o campo (ou conjunto de campos) utilizado para interligar um arquivo a outros. 2. Geralmente, as chaves estrangeiras ou apontadoras de cada arquivo tambm devem ser indexadas. Chaves estrangeiras so campos ou concatenaes de campos que possuem valores que so chaves primrias em outros arquivos de dados relacionados. 3. A seguir, cada campo que possa ser utilizado em uma consulta de resposta rpida, em geral na tela, deve ser considerado candidato indexao (chaves candidatas). 4. Finalmente, qualquer campo que for utilizado para ordenar um arquivo de dados candidato para ser chave de um arquivo de ndice. Melhorando o Desempenho Dois casos muito comuns de queda de desempenho so o excesso de relacionamento entre arquivos e a totalizao de dados. No primeiro caso, mesmo que, independentemente dos ndices que tiverem sido criados, o tempo de resposta envolvendo o relacionamento de vrios arquivos no for aceitvel, poder ser necessrio efetivar o relacionamento, isto , combinar fisicamente dois ou mais arquivos para fazer um arquivo interligado que seja mantido como um nico arquivo, desrespeitando as regras de normalizao. Se o sistema for corretamente implementado para tratar os arquivos combinados desta forma no haver problema em desrespeitar as regras de normalizao. No segundo caso, mesmo que os arquivos estejam indexados e otimamente relacionados, voc ainda poder verificar que levar muito tempo para o sistema responder a consultas envolvendo totalizaes. A soluo ser criar um novo arquivo, especialmente para a totalizao, que seja periodicamente processado, e as totalizaes nele atualizadas. O inconveniente aqui que as atualizaes dos totais no sero on-line e, consequentemente os totais podero estar desatualizados se a rotina de atualizao ainda no tiver sido processada. Alm destes casos, existem vrios outros, que dependem de particularidades de cada sistema, nos quais ser vlido desrespeitar as regras de normalizao para melhorar o desempenho e facilitar sua implementao fsica, obtendo-se uma base de dados equilibrada. Cabe ao desenvolvedor decidir sobre quando e como ser vlido desrespeitlas. Entretanto, as melhores decises viro apenas com a experincia.
75
Definio dos Mdulos do Sistema

Introduo Na grande maioria dos sistemas, o modelo de processos do negcio precisa ser subdividido em partes contendo procedimentos automatizados e/ou manuais, para que o sistema possa ser desenvolvido e executado em unidades menores, mais fceis de serem implementadas, testadas e operacionalizadas. Estas partes do BPM, que denominaremos de mdulos, podero ser um programa, um procedimento manual ou automatizado, uma relao de operaes ou comandos, ou um combinao dos trs. Um mdulo sempre ser invocado como uma unidade, normalmente por uma opo de um menu, e constitui uma operao ou procedimento completo que o sistema deve executar. Deve ser uma operao que possa ser vista pelos prprios usurios do sistema como uma unidade. Normalmente, os mdulos esto relacionados com entradas e sadas de dados, manuteno de arquivos, clculos e outras operaes especiais que o sistema deve efetuar. As seguintes operaes poderiam ser vistas como sendo mdulos de um sistema: Processamento de um pedido de compra; Clculo da folha de pagamento; Emisso de relatrios; Cadastro de novos produtos; Alterao de dados de clientes; Excluso de um fornecedor; Gravao do histrico de vendas; Gravao de cpias de segurana dos arquivos; Etc. A diviso de um sistema em mdulos deve ser natural, ou seja, determinados procedimentos ou operaes, que guardem entre si uma mesma relao de contexto ou funo devem ser agrupados em um mdulo. Os processos definidos pelo BPM e as entidades e os eventos descritos no RDM podem ser agrupados ou categorizados para definir os mdulos do sistema. Aps este trabalho, uma relao de todos os mdulos deve ser efetuada, e cada um dever receber nmeros ou nomes que correspondam aos processos lgicos definidos no BPM, que atravs deles sero implementados.
76
A rvore do Sistema Quanto maior for o sistema sendo projetado, maior ser o nmero de mdulos necessrios para implementar todos os processos e operaes previstos no BPM. Os mdulos definidos, de acordo com o contexto e funo no qual se encaixam, normalmente guardam uma relao de hierarquia entre si, ou seja, existem nveis de processos e operaes que sero desempenhados pelo sistema, do mais abrangente para o mais especfico. Esta hierarquia de mdulos d origem ao que denominamos rvore do sistema. A rvore do sistema um diagrama, semelhante a um organograma, que identifica cada um dos mdulos e a hierarquia existente entre eles. Normalmente, a rvore do sistema determina a estrutura de menus de operaes do sistema, pois cada mdulo, de acordo com o seu nvel, dar acesso ou executar uma determinada operao. A Fig. 29 ilustra parte da rvore do sistema de controle de aluguel de vdeo locadoras (SISVIDEO), que tambm foi utilizado para exemplificar o BPM e o RDM. Recomendamos que a rvore do sistema sempre seja desenhada. Alm de naturalmente definir a hierarquia de operaes e correspondentes menus de opes para o desenvolvedor, ela fornece aos usurios uma idia bastante clara da abrangncia e da estrutura de operao do sistema.
SISVDEO
CADASTROS
ALUGUL
RELATRIOS
UTILITRIOS
GNERO
RETIRADA
CLIENTES
PARMETROS
FILMES
DEVOLUO
FILMES
USURIOS
CPIAS
ATRASADOS
ALUGUIS . . .
CLIENTES ESTATSTICO
Fig. 31 - rvore do Sistema 77
Especificao dos Mdulos do Sistema

Introduo Tendo sido definidos os principais mdulos e elaborada a rvore do sistema, como cada um deles est relacionado com o modelo de processos do negcio e, consequentemente, com os arquivos da base de dados do sistema, seu desenvolvimento e testes devero ser planejados. Normalmente, produzida e revista uma especificao escrita para cada mdulo. Esta especificao, em teoria, dever conter toda informao necessria para que algum que conhea a ferramenta de software com a qual ser desenvolvido o sistema possa produzir o cdigo ou programas necessrios para cada um de seus mdulos. Entretanto, medida que as ferramentas ficam mais potentes e forem construdas bibliotecas de rotinas e/ou objetos, o cdigo do sistema se assemelhar cada vez mais com a prpria especificao dos mdulos, de modo que eventualmente a especificao desaparecer como um documento distinto, e cada mdulo ser gerado diretamente por algum que conhea a empresa. Utilizando uma ferramenta moderna para desenvolver o sistema, normalmente h dois tipos de diviso do trabalho de especificao e codificao de seus mdulos: Uma pessoa: implementao na qual o desenvolvedor, alm da especificao dos mdulos, tambm responsvel pela sua codificao e testes; Vrias pessoas: implementao em que o desenvolvedor especifica os mdulos, e um ou mais programadores os codificam e testam, trabalhando em contato ntimo com o desenvolvedor. Implementao por Uma Pessoa Atravs da implementao por "uma pessoa", os mdulos do sistema precisam ser especificados apenas at o ponto em que o desenvolvedor tenha um quadro mental claro dos formatos de entrada e sada de dados, e da lgica interna, pois a rea do modelo de processos do negcio envolvida foi definida e os arquivos a serem acessados tambm j foram definidos. Se as telas ou formulrios do sistema forem gerados por um construtor automtico, o desenvolvedor deve saber que campos ou dados aparecero em cada tela, mas poder utilizar o prprio construtor de telas para definir a posio exata dos campos. Se no for utilizado um construtor de telas e cada formato de tela tiver que ser codificado detalhadamente, ser mais rpido produzir em papel um layout exato da tela, antes de comear a codificar.
78
Se os relatrios forem gerados por um "construtor automtico de relatrios", o desenvolvedor deve saber que dados sero impressos em cada relatrio, mas poder utilizar o prprio construtor de relatrios para definir a posio exata dos dados. Se no for utilizado um construtor de relatrios e cada um tiver que ser codificado detalhadamente, ser mais rpido produzir em papel um layout exato de cada relatrio, antes de comear a codific-los. Se o menu de operaes do sistema for gerado por um "construtor automtico de menus", o desenvolvedor deve utilizar diretamente a rvore do sistema para defini-lo, associando a cada opo a tela, o relatrio ou a operao a ser executada. Implementao por Vrias Pessoas Atravs da implementao por "vrias pessoas", o desenvolvedor precisa entregar: 1. O BPM do sistema como um todo; 2. O RDM do sistema; 3. O contedo dos arquivos de dados com o detalhamento de cada dado; 4. A rvore do sistema; 5. Os layouts de telas ou formulrios e de relatrios que tiverem sido definidos at o momento para cada mdulo considerado; 6. Explicaes e detalhes para os textos de dilogos sistema x usurio; 7. Explicaes e detalhes para a lgica de programao ou regras de negcio de cada processo de cada mdulo. Neste caso, os programadores precisam ser orientados sobre as caractersticas da empresa e sobre os objetivos do sistema. A interseo entre a anlise e a programao no ser distinguvel no projeto por "vrias pessoas". Os programadores podero trabalhar em contato com o usurio para refinar detalhes de formatos de tela, relatrios, dilogos sistema x usurio e a prpria lgica dos mdulos. Dilogo Sistema x Usurio Alm da especificao dos formatos de tela e relatrios e da prpria lgica dos mdulos, importante ter-se uma definio clara dos dilogos do sistema com o usurio ou operador. A representao dos dilogos pode ser feita como se fosse um roteiro de pea de teatro. Um trecho de definio de dilogos sistema x usurio, seguindo o roteiro pea teatral ilustrado a seguir.
79
A especificao do dilogo sistema x usurio deve ser lgica, simples, clara e objetiva. Detalhes devem ser omitidos, e apenas o fluxo lgico essencial deve ser especificado. Tenha em mente que um desenvolvedor ou programador no gosta de ler muito papel, e os detalhes de programao devem fazer parte de sua qualificao como tal.
Ator Sistema Usurio Sistema Sistema Usurio Sistema Solicita a senha de acesso. Digita a senha. Apresenta o menu principal se a senha estiver correta. Apresenta uma mensagem de erro e finaliza se a senha estiver incorreta. Escolhe a opo para incluso de pedidos de venda. Apresenta a tela de entrada de pedidos de venda e solicita o nmero do pedido. Ao
. .
. .
Exemplo de Especificao de Mdulo

Definio
Nome: Descrio: Entrada de Pedidos de Vendas. Permite que o vendedor digite os produtos solicitados pelo cliente, bastando digitar o nmero do pedido, o cdigo do cliente, o cdigo dos produtos e as respectivas quantidades desejadas.
Processamento: Todo o tempo em que a empresa estiver aberta. Iniciado por entrada on-line.
Trecho do BPM:
80
Arquivos Acessados:
CLIENTE VENDEDOR PRODUTO VENDA ITEM VENDIDO
Formato de Tela:
PEDIDOS/INCLUSO PEDIDO N: CLIENTE: VENDEDOR: DATA: ICMS: Cdigo 1.1.001 2.2.002 3.3.003 . . . SISTEMA SAO
0001 012 AGV TREIN.DESENV.DE SISTEMAS LTDA. 001 ROLANDO LERO 30/02/99 18,00% Produto Disquete 5 1/4" 360K Formulrio 80 colunas Fita Impressora . . . Preo 2,00 10,00 5,00 . . . Qtd. 20 3 4 . . . Total 40,00 30,00 20,00 . . .
Formato de Relatrio:
=========================================================== SISTEMA DE ADMINISTRAO DE OPERAES AGV INFORMTICA LTDA. =========================================================== CLIENTE: 012 AGV TREIN.DESENV.DE SISTEMAS LTDA. VENDEDOR: 001 ROLANDO LERO DATA: 30/02/99 ICMS: 18,00% ----------------------------------------------------------Cdigo Produto Preo Qtd. Total 1.1.001 Disquete 5 1/4" 360K 2,00 20 40,00 2.2.002 Formulrio 80 colunas 10,00 3 30,00 3.3.003 Fita Impressora 5,00 4 20,00 ----------------------------------------------------------TOTAL 90,00 IMPOSTO 16,20 TOTAL GERAL 106,20 ===========================================================
81
Detalhes do Processamento:
Operador Digita o nmero do pedido Digita a data do pedido Digita o cdigo do cliente Digita o cdigo do vendedor Digita o cdigo do produto Digita a quantidade pedida Sistema Verifica o pedido j est cadastrado. Se estiver, apresenta mensagem de erro e solicita um novo nmero. Se no estiver, solicita a data do pedido. No aceita enquanto a data no for vlida. Verifica se o cliente existe. Se existir, apresenta o nome do cliente. Se no existir, solicita novamente at que seja digitado um cliente vlido, ou seja cancelado com <Esc>. Verifica se o vendedor existe. Se existir, apresenta o nome do vendedor. Se no existir, solicita novamente at que seja digitado um vendedor vlido, ou seja cancelado com <Esc>. Verifica se o produto existe. Se existir, apresenta o nome do produto e o preo de venda. Se no existir, solicita novamente at que seja digitado um produto vlido, ou seja finalizado com <Esc>. Verifica se h saldo no estoque suficiente para atender o pedido. Se no houver, apresentar mensagem recusando o produto e solicitar outro Se houver aceita o produto e d baixa no saldo do estoque.
Altera o preo de venda Registra o novo preo de venda. Digita o cdigo de outro produto Finaliza a entrada Se o cdigo do produto no for deixado em branco, solicita um novo produto e repete as operaes; em caso contrrio, finaliza a entrada. Grava os dados nos respectivos arquivos.
Toda a informao suprflua deve ser eliminada do detalhamento do processamento. Determinadas operaes padronizadas, como por exemplo, seta para cima retorna para o dado anterior e seta para baixo avana para o seguinte, no devem ser descritas. Como desenvolvedor voc dever supor que os seus programadores so suficientemente qualificados para compreenderem o processamento de um mdulo sem que voc tenha que se perder em detalhes. Alm de gerar uma quantidade muito grande e desnecessria de papel, detalhes esto mais sujeitos a mudanas, enquanto que a essncia do processamento no.
82
Bibliografia
Bio, Srgio Rodrigues Sistemas de Informao: Um Enfoque Gerencial So Paulo, Atlas, 1985 Gane, Chris Desenvolvimento Rpido de Sistemas Rio de Janeiro, LTC, 1988 Gane & Sarson Anlise Estruturada de Sistemas Rio de Janeiro, LTC, 1983
83

Introduo Ao Projeto e To de Sistemas de Infor

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduo Ao Projeto e To de Sistemas de Infor

Uploaded by

Copyright:

Available Formats

INTRODUO AO PROJETO E DESENVOLVIMENTO DE SISTEMAS DE INFORMAO

Prof. ANTONIO GERALDO DA ROCHA VIDAL

FEA/USP - EAD-451 Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

O Conceito de Sistema de Informao

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

Fig. 01 Sistema empresa

Fig. 02 O subsistema de produo

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

Requisitos de um Sistema de Informao

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

Metodologia para Identificao das Necessidades de Informao

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

Levantamento das reas de Aplicao da Informtica

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

Aplicao Faturamento Contas a Receber

rea Vendas Financeiro

Vendas Financeiro Contabilidade

Compras Almoxarifado Contas a Pagar

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

Definio dos Requisitos de um Sistema de Informao

Dados a Serem Processados

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

ARQUIVO DE ORIGEM DOS PRODUTOS

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

Fig. 03 Esquema de arquivos de ndice e da busca binria

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

Etapas do Projeto de Sistemas

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

Modelo de Processos do Negcio (BPM)

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

Fig. 04 Entidades externas

Fig. 05 Fluxo de dados de e para uma entidade externa

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

Fig. 06 Duplicao de entidades externas no BPM

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

Fig. 07 Fluxos de dados

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal

Fig. 09 Representao de arquivos de dados

Fig. 10 Duplicaes de arquivos de dados

FEA/USP / EAD-451- Informtica Aplicada Administrao - Prof. Antonio Geraldo Vidal