apostilawaldoifpr.pdf

SumSumriorio

1 - Sistemas de Informao, Engenharia de Software e Tcnicas Estruturadas, 1

Sistemas de Informao, 1Engenharia de Software, 6Tcnicas Estruturadas, 11

2 - Levantamento de Dados, 17

Objetivos da entrevista, 17Diretrizes para a entrevista, 18Documentao dos requisitos do sistema, 19

3 - Diagrama de Fluxo de Dados (DFD), 21

Consideraes iniciais, 21Smbolos do DFD, 23Sintaxe do DFD, 24Nveis de representao do DFD - tcnicas de fracionamento da complexidade e expanso, 26Diretrizes para desenhar um DFD, 27Exerccios, 29

4 - Especificao de Processos, 47

Portugus Estruturado, 47Pseudocdigo, 51Tabela de Deciso, 52rvore de Deciso, 54Concluso, 55Exerccios, 57

5 - Dicionrio de Dados, 69

Conceito, 69Notao, 70Regras para construo do Dicionrio de Dados, 70Exemplo, 70Exerccios, 72

6 - Diagrama de Estrutura, 77

Componentes do Diagrama de Estrutura, 77Estratgias para transformao do DFD em Diagrama de Estrutura, 79Anlise de Transformao, 79Anlise de Transao, 80Avaliao do projeto, 82Exerccios, 84

11

Sistemas de InformaSistemas de Informao,o,Engenharia de Software eEngenharia de Software e

TTcnicas Estruturadascnicas Estruturadas11

Neste capNeste captulotulo::

Contexto da Sistema deContexto da Sistema deInformaInformaoo

Engenharia de SoftwareEngenharia de Software

Ciclos de vida deCiclos de vida dedesenvolvimento de sistemasdesenvolvimento de sistemas

TTcnicas Estruturadascnicas Estruturadas

PrincPrincpios das Tpios das TcnicascnicasEstruturadasEstruturadas

O objetivo deste texto apontar algumas questes bsicas para a compreenso da funo do analista de sistemas em uma organizao. Ele enfocar os conceitos de Sistemas de Informao, Engenharia de Software e Tcnicas Estruturadas.

A formao de um(a) profissional para a funo de analista de sistemas deve levar em conta que este profissional atuar na avaliao de sistemas e no desenvolvimento de sistemas automatizados, projetando, tambm, mudanas de procedimentos (inclusive aqueles realizados sem o uso de computador). Neste sentido, o desenvolvimento de sistemas o foco central da atuao do analista de sistemas. Por isto, fundamental compreender que este um campo profissional, que deve ser trabalhado com a utilizao de tcnicas cientificamente desenvolvidas para que o processo de desenvolvimento de sistemas, bem como seus resultados, tenham qualidade.

Para compreender o processo de desenvolvimento de sistemas, necessrio ter claro o conceito de sistema. Muitas definies podem ser feitas de sistemas. Eles esto ao nosso redor e, at mesmo, dentro de ns (o nosso organismo um sistema vivo). Na tentativa de fazer uma definio que tente ser simples e consensual, podemos dizer que sistema um conjunto organizado de partes que atuam integradamente visando alcanar algum(ns) objetivo(s).

Desta forma, podemos afirmar que um sistema

definido a partir da identificao de suas partes e a

constatao de que elas atuam numa mesma direo e

sentido, resultando em algo que pode ser definido

como sendo seu objetivo.

Exemplificando, nosso organismo um sistema,

formado por muitas partes, que tem por objetivo

manter-nos vivo. Todas as aes e resultados gerados

pelas partes deste sistema so empregados no objetivo

de ter vida.

Sistemas de Informao

22

Podemos citar, tambm, uma empresa que registra toda a sua movimentao financeira e compromissos de pagamento em um sistema contbil. Este sistema tem uma srie de funes, como a gerao de lanamentos, a escriturao fiscal, a emisso de relatrios gerenciais. Este conjunto de funes delimita um sistema que tem como objetivo a contabilidade da organizao.

Os sistemas, em uma das inmeras classificaes possveis de serem feitas, pode ser naturais ou feitos pelo homem. Um sistema natural est relacionado s partes ordenadas que existem independente da ao humana. Como exemplo deste tipo de sistema, podemos citar o sistema solar, um ecossistema, sistema reprodutor, sistema digestivo, etc.

Os sistemas feitos pelo homem so aqueles gerados pela ao humana, atravs da organizao de funes visando a um objetivo comum. Por exemplo, sistema mecnico de um carro, sistema de ventilao de um prdio, sistemas eltricos, sistemas hidrulicos, sistemas de informao, etc.

Os sistemas, de forma geral, so organizados em hierarquias. Ou seja, um sistema geralmente parte de um sistema maior, da mesma forma como pode ser decomposto em sistemas menores. Como exemplo, podemos citar o ser humano como sendo um sistema composto por sistemas menores (chamados de sub-sistemas), como sistema respiratrio, sistema muscular, dentre outros, ao mesmo tempo em que compe outros sistemas como a famlia, a comunidade, etc. Da mesma forma, uma empresa faz parte de um sistema produtivo de uma comunidade, ao mesmo tempo em que possui sub-sistemas, como de recursos humanos, produo, contabilidade, compras, vendas, etc.

Considerando estes aspectos, um importante elemento na anlise de sistemas a delimitao do escopo do sistema a ser analisado. Isto significa definir a abrangncia do mesmo e o seu grau de detalhamento. Da mesma forma como impossvel analisar um sistema de sade pblico de uma forma global, se nos detivermos a detalhes de funcionamento do sistema respiratrio de cada indivduo que faz parte da comunidade que est sendo avaliada, isto ocorre tambm no exerccio da funo de anlise de sistemas. importante que o(a) analista de sistema tenha clareza da hierarquia de sistemas e sub-sistemas envolvidos em seu trabalho para que possa ter a percepo correta dos objetivos, sem se perder em detalhes desnecessrios, mas sem divagar exageradamente pela abstrao do que est sendo trabalhado.

Como parte inerente funo de analista de sistemas, h uma categoria especfica de sistemas onde este profissional atua. Trata-se dos chamados Sistemas de Informao. Muitas definies podem ser dadas para a expresso Sistema de Informao. Tentando contemplar as principais definies, podemos dizer que sistema de informao o sistema que utiliza e gera informaes para atender seus objetivos. Exemplificando, podemos dizer que o apontamento de mo-de-obra em uma fbrica um sistema de informao, pois ele alimentado com dados sobre o trabalho de cada funcionrio na realizao de tarefas especficas e gera informaes consolidadas sobre o produto gerado pelo trabalho dos funcionrios na fbrica.

Um sistema de informao localizado em organizaes, das mais distintas naturezas, levando em conta duas dimenses: os componentes da organizao e o nvel de deciso. A dimenso dos componentes da organizao diz respeito s reas funcionais, unidades organizacionais, setores ou departamentos, que realizam funes dentro do sistema ou o alimentam ou recebem informaes.

O nvel de deciso diz respeito abrangncia das informaes geradas e para quais executivos da organizao. Os nveis de deciso so classificados geralmente em nvel estratgico, nvel ttico ou gerencial e nvel operacional.

O nvel estratgico corresponde s decises do alto escalo administrativo da organizao, correspondendo s grandes polticas institucionais, definindo rumos de longo prazo e de efeitos duradouros.

O nvel ttico ou gerencial corresponde s decises intermedirias da organizao, subsidiando ou emanando das decises de nvel estratgicos, relacionando-se basicamente ao controle gerencial de funes especficas.

O nvel operacional est relacionado diretamente com o funcionamento da organizao, no atendimento s polticas e diretrizes institucionais (emanadas no nvel estratgico), dentro de padres estabelecidos e regulamentados internamente (a partir de decises de nvel ttico).

Quando tratamos de Sistemas de Informao, devemos observar cinco consideraes bsicas: objetivos do sistema; ambiente do sistema; recursos do sistema; componentes do sistema; e administrao.

Os objetivos do sistema so fundamentais para que o mesmo possa ser analisado e desenvolvido. um fator onde o(a) analista de sistemas deve deter-se com bastante cuidado sem cair na tentao de achar que os objetivos esto claros, pelo fato de que o usurio pode citar quais so eles, e partir para as demais tarefas da anlise. Na verdade, se os objetivos no forem muito bem definidos,dificilmente o sistema atingir seu sucesso. Muitas vezes ocorre que os objetivos declarados dosistema no corresponde aos objetivos reais. Neste sentido, o(a) analista de sistemas deve procurar ouvir o mximo de pessoas envolvidas com os sistemas, procurando assegurar-se de que os objetivos esto realmente estabelecidos para o desenvolvimento de determinado sistema. Para isto, ele(a) deve tentar entender no somente os fatos relativos ao sistema, mas tambm a lgica que est por trs dos fatos, avaliando a compreenso dos diferentes nveis e categorias de usurios sobre os objetivos, uma vez que os diferentes agentes envolvidos no sistema geralmente tm vises diferentes dos objetivos do sistema.

O ambiente do sistema envolve elementos que esto fora do sistema, mas influenciam ou podem influenciar o sistema. Isto significa que o sistema no tem controle sobre estes elementos, mas no pode desconsider-los, uma vez que uma mudana de comportamento em um destes elementos pode provocar alteraes ou, at mesmo, a destruio de um determinado sistema. Por exemplo, a legislao trabalhista no faz parte de um sistema de folha de pagamento, mas participa do ambiente do sistema. O sistema no pode mudar ou influenciar a legislao, mas qualquer mudana que ocorra nela, haver conseqncias para o sistema. Conhecer o ambiente do sistema um elemento fundamental para o(a) analista de sistemas possa realizar seu trabalho. Neste sentido ele(a) no pode e no deve ficar restrito apenas s variveis que emergem do prprio sistema, como sendo os nicos elementos a serem considerados no desenvolvimento de um sistema.

33

44

Os recursos do sistema envolvem tudo aquilo que necessrio para que o sistema seja executado. Isto implica em pessoas, dinheiro, equipamentos, materiais, etc. Os recursos esto sob controle do sistema, uma vez que a falta deles implica no no-funcionamento do mesmo.

Os componentes do sistema so as partes que compem o sistema e so responsveis pela execuo de suas funes.

A administrao do sistema consiste na integrao dos demais elementos considerados, uma vez que ela implica em planejar e acompanhar as funes do sistema, incluindo sua relao com o ambiente, a alocao de recursos, a atribuio aos componentes, para que os objetivos seja atingidos.

Um tipo especfico de sistema de informao o sistema baseado em computador, ou sistema de processamento de dados, ou, ainda, sistema automatizado. Este tipo de sistema aquele que organizado em termos de mtodo, procedimento ou controle, realizando processamento de informaes atravs de computador. O esquema bsico de um sistema baseado em computador estrepresentado pela Figura 1.1.

Figura 1.1. Esquema bsico do processamento de dados.

Um sistema baseado em computador possui os seguintes elementos bsicos: software, hardware, pessoas, documentao, banco de dados e procedimentos.

O software corresponde aos sistemas operacionais, linguagens de programao, ambientes de desenvolvimento de software, ferramentas de programao, compiladores, sistemas gerenciadores de banco de dados, sistemas de rede, etc.

O hardware inclui os computadores, perifricos e ligaes de rede e comunicao usados no sistema.

As pessoas envolvidas no sistema so usurios, desenvolvedores, pessoal de manuteno e alimentao de dados, gerentes, etc.

Por documentao compreende-se o conjunto de documentos gerados no processo de desenvolvimento do sistema, bem como instrues de uso, alm dos documentos usados como base para a alimentao do sistema e os gerados por ele.

O banco de dados inclui o conjunto de dados armazenados permanentemente ou provisoriamente em meios magnticos, recuperveis pelo sistema computadorizado.

Os procedimentos incluem tanto aqueles necessrios para a utilizao do sistema, quanto aqueles que so realizados manualmente, mas possuem interface com o sistema informatizado.

A Figura 1.2 apresenta um resumo da interao entre os elementos bsicos de um sistema baseado em computador. O sistema o elo integrador entre os diferentes elementos que o constitui.

55

Figura 1.2. Interao entre os elementos bsicos de um sistema baseado em computador.

Os sistemas baseados em computador podem ser classificados em diversos tipos. A seguir veremos alguns tipos mais comuns. Convm ressaltar que esta classificao no mutuamente exclusiva, ou seja, um mesmo sistema pode enquadrar-se em diversas categorias aqui elencadas.

Sistemas on-line: so sistemas em que h interao direta entre usurio e sistema e os dados de entrada so alimentados diretamente do local onde so criados e os dados de sada so direcionados diretamente para onde so usados. Estes sistemas tm as seguintes caractersticas: processamento remoto; dados organizados de maneira que permita a recuperao rpida; e interao com o usurio.

Sistemas batch (ou sistemas em lote): so aqueles que processam os dados seqencialmente, a partir de lotes gerados por meio de digitao proveniente de documentos, gerando resultados que so disponibilizados para posterior utilizao. Tm as seguintes caractersticas: grande volume de informaes; no h interao com o usurio; e processamentos longos.

Sistemas distribudos: so sistemas on-line que possuem usurios distribudos em pontos geogrficos diferentes, interagindo, atravs de linhas de comunicao, para ter acesso aos mesmos programas e dados.

Sistemas centralizados: so aqueles cujos usurios os utilizam a partir de um mesmo local geogrfico, a partir de programas e dados armazenados dispostos em um mesmo local.

Sistemas de tempo real (ou real time): so sistemas que controlam um ambiente atravs do recebimento de dados e seu processamento, gerando resultados com rapidez suficiente para afetar o ambiente no mesmo momento. Suas caractersticas so: ocorrncia de atividades de processamento simultneas; prioridades diferentes para as diferentes tarefas; interrupo de tarefas menos prioritrias; e acesso simultneo a dados.

Sistemas transacionais: so aqueles que baseiam-se em registro de transaes para posterior recuperao. Podemos dizer que os sistemas transacionais automatizam procedimentos que, pelo volume e freqncia de dados, poderiam estar sujeitos a muitos erros se processados manualmente, mas no proporcionam, diretamente, elementos para uma tomada de deciso mais abrangente.

66

Sistemas de apoio deciso (SAD) (ou Support Decision Systems DSS): so aqueles que geram informaes para tomada de decises no nvel ttico ou gerencial, atravs de snteses de transaes e facilidades de consultas flexveis, que so definidas em funo da questo sobre a qual pretende-se tomar deciso.

Sistemas baseados em conhecimento (ou sistemas especialistas): so aqueles que simulam o conhecimento humano de um especialista para equacionar um problema e executar tarefas inteligentes.

Sistemas de Informao Executiva (ou Executive Information Systems EIS): so sistemas de apoio tomada de decises aos executivos de nvel estratgico de uma organizao. Estes sistemas baseam-se em uma estrutura de dados corporativos altamente flexvel do ponto de vista de formulao de consultas, incluindo elementos referentes s estratgias de negcio da organizao e dados da concorrncia para obter-se um comparativo.

Sistemas integrados de gesto empresarial (ou Enterprise Resource Planning ERP): so sistemas que integram todas as funes bsicas de negcio de uma organizao, gerando um alto grau de informaes relativas ao funcionamento da empresa, permitindo tomada de decises nos mais diferentes nveis da organizao.

Os sistemas, de um modo geral, e os sistemas de informao, de forma especfica, principalmente os sistemas baseados em computador, seguem os seguintes princpios (segundo Eduard Yourdon, em Anlise Estruturada Moderna (Ed. Campus, 1990):quanto mais especializado um sistema, menos capaz ele de se adaptar a circunstncias diferentes;quanto maior for um sistema, maior o nmero de seus recursos que sero destinados manuteno diria;os sistemas sempre fazem parte de sistemas maiores e sempre podem ser divididos em sistemas menores;os sistemas crescem.

Yourdon tambm cita que o desenvolvimento de sistemas uma atividade que envolve muitos participantes. Estes participantes so: usurios; gerentes; coordenadores ou lderes de projeto; analistas de sistemas; projetistas de sistemas (normalmente o(a) prprio(a) analista de sistema); programadores; e pessoal de apoio e de produo.

Engenharia de Software

Roger S. Pressman, em seu clssico livro Engenharia de Software (Ed. Makron, 1995), traz a primeira definio para Engenharia de Software, feita por Fritz Bauer, que o estabelecimento e uso de slidos princpios de engenharia para que se possa obter economicamente um software que seja confivel e que funcione eficientemente em mquinas reais. Outra definio complementar pode ser feita como sendo o conjunto de mtodos, ferramentas e procedimentos que estabelecem o

77

uso de princpios de engenharia (formalizao), que, por sua vez, permite o gerenciamento e controle dos processos de desenvolvimento de software a fim de obter um produto final com maior qualidade, estabilidade, sendo desenvolvido de forma mais produtiva.

Nestas definies, encontramos palavras-chave como confiabilidade, produtividade, qualidade e estabilidade que, quando aplicadas ao software, significa uma nova maneira de produzir software, no de maneira artesanal ou amadora, mas de forma profissional, dentro de modernos e rigorosos princpios que tornam o produto final (software) melhor.

Os seguintes elementos so aplicados na Engenharia de Software: mtodos; ferramentas; procedimentos. Os mtodos correspondem ao como fazer. As ferramentas do suporte aos mtodos. Os procedimentos consistem em regras para a aplicao dos mtodos e ferramentas.

A Engenharia de Software pressupe o uso de uma Metodologia de Desenvolvimento de Sistemas. Metodologia de Desenvolvimento de Sistemas (MDS) o conjunto de atividades a serem desenvolvidas para a gerao de um sistema ou software. Ela deve envolver os elementos que so aplicados na Engenharia de Software.

A Figura 1.3 mostra a relao, proposta por Wasserman no artigo Automated Tools in the InformationSystem Development Environments (Proceedings of the IFIP WG 8.1 Working Conference, 1982), entre os elementos da Engenharia de Software em uma Metodologia de Desenvolvimento de Sistemas.

Figura 1.3. Relao entre os elementos da Engenharia de Software em uma Metodologia deDesenvolvimento de Sistemas.

Uma Metodologia de Desenvolvimento de Sistemas pressupe a existncia de um ciclo de vida para a realizao das tarefas inerentes ao desenvolvimento de sistemas. Ciclo de vida a seqncia e a interao em que as atividades de desenvolvimento de sistemas so executadas. O ciclo de vida deve envolver todos os passos desde a concepo do sistema at sua implementao em termos de cdigo executvel testado e utilizvel pelo usurio final.

Os objetivos da adoo de um ciclo de vida pela organizao podem ser definidos como: definir as atividades a serem executadas no desenvolvimento de sistemas; introduzir consistncia entre muitos

88

projetos de desenvolvimento de sistemas dentro da organizao; e introduzir pontos de verificao para o controle gerencial de decises.

Existem vrios paradigmas de Engenharia de Software, cada um com ciclo de vida especfico. Dentro do escopo proposto, analisaremos alguns ciclos de vida para as metodologias de desenvolvimento de sistemas estruturadas.

O ciclo de vida clssico aquele que requer uma abordagem sistemtica e seqencial do desenvolvimento, envolvendo as seguintes fases: anlise e engenharia de sistemas; anlise de requisitos de software; projeto; codificao; testes; e manuteno. A Figura 1.4 ilustra este ciclo de vida.

Figura 1.4. Ciclo de vida clssico.

A fase de anlise e engenharia de sistemas consiste em estabelecer os requisitos para todos os elementos do sistema e atribuir alguns destes requisitos ao software a ser desenvolvido.

A fase de anlise de requisitos de software consiste no detalhamento dos requisitos levantados na fase anterior, atendo-se mais especificamente aos elementos relacionados s partes informatizadas do sistema, buscando compreender o domnio da informao para o software, as funes, desempenho e interface necessrios.

A fase de projeto consiste em definir a estrutura de dados a ser usada como suporte para o sistema, a arquitetura do software, detalhes de procedimentos para a utilizao do sistema e a caracterizao da interface. Esta definio deve ser avaliada antes de iniciar-se a codificao, para assegurar a qualidade exigida.

A fase de codificao consiste na gerao dos programas correspondentes s funes do sistema.

A fase de testes consiste em avaliar se todas as instrues geradas na codificao esto corretas, bem como se o sistema responde adequadamente s entradas do sistema no que diz respeito a sua funcionalidade.

A manuteno corresponde realizao de mudanas no sistema provocadas pela descoberta de erros (manuteno corretiva), ou pela necessidade de adaptar-se a mudanas no ambiente ou na

99

necessidade do usurio (manuteno adaptativa), ou, ainda, pela necessidade de introduzir-se novas funes para o usurio (manuteno evolutiva). No momento da manuteno, aplica-se as mesmas fases do desenvolvimento de um novo sistema, com a nica diferena sendo a aplicao destas fases a um sistema j existente.

O ciclo de vida clssico possui os seguintes problemas: os projetos reais raramente seguem o fluxo seqencial que o modelo prope; muitas vezes h dificuldades para que o usurio defina os requisitos do sistema de uma s vez, uma vez que o modelo no se adapta incerteza natural que existe no incio do processo de desenvolvimento de um sistema; e os primeiros resultados para o usurio somente sero percebidos nas fases mais avanadas do processo, quando muito tempo se passou, podendo ser invivel proceder alguma alterao, cuja necessidade percebida tardiamente.

Outro paradigma o do ciclo de vida semi-estruturado. Este ciclo apresenta duas caractersticas inexistentes no ciclo de vida clssico: substituio da seqncia bottom-up de codificao pela implementao top-down (os mdulos de mais alto nvel so codificados e testados antes dos de mais baixo nvel); substituio do projeto clssico (desenho de lay-outs de arquivos, telas e relatrios) pelo Projeto Estruturado (que uma abordagem formal de projeto de sistemas). A Figura 1.5 ilustra o ciclo de vida semi-estruturado.

Figura 1.5. Ciclo de vida semi-estruturado.

A implementao top-down, muitas vezes, leva realimentao entre o processo de implementao e o processo de anlise.

Outro modelo o ciclo de vida estruturado, que corresponde s fases do desenvolvimento de sistemas atravs da tcnica conhecida como Anlise Estruturada. A Anlise Estruturada, juntamente com o Projeto Estruturado e a Programao Estruturada compem um paradigma de Engenharia de Software, que a Metodologia Estruturada de Desenvolvimento de Sistemas. A Figura 1.6 mostra as fases deste ciclo de vida e a Tabela 1.1 mostra os objetivos de cada fase.

1010

Figura 1.6. Ciclo de vida estruturado.

Fase do ciclo devida

Objetivos da fase

1. Levantamentode dados

identificar os usurios responsveis; desenvolver um escopo inicial do sistema; identificar as atuais deficincias no ambiente do usurio; estabelecer metas e objetivos para um novo sistema; determinar se possvel automatizar o sistema e, se assim for, sugerir alguns esquemas

aceitveis; preparar uma previso do projeto que ser usada para conduzir o restante do projeto.

2. Anlise dosrequisitos

transformar os dados obtidos no levantamento em especificaes estruturadas; fazer a modelagem do ambiente do usurio; fazer a anlise custo x benefcio dentro do estudo de viabilidade do projeto.

3. Projeto alocar as especificaes geradas na anlise aos respectivos processadores (homem oumquina);

definir as tarefas relativas a cada especificao; transformar modelos de dados em projeto de banco de dados; definir os mdulos a serem codificados.

4. Implementao codificar os mdulos definidos na fase de projeto; integrar os mdulos codificados.

5. Gerao doteste de acietao

avaliar se as especificaes estruturadas so aceitveis do ponto de vista do usurio.

6. Controle dequalidade

garantir que o sistema apresentar o nvel apropriado de qualidade.

7. Descrio deprocedimentos

gerar uma descrio formal das partes do novo sistema que sero manuais; gerar uma descrio de como os usurios devero interagir com a parte automatizada do

novo sistema; gerar o manual do usurio.

8. Converso debanco de dados

converter o banco de dados existente (informatizado ou no) em um banco de dadoscoerente com a especificao do projeto.

9. Instalao colocar o sistema gerado em funcionamento em consonncia com o manual do usurio e obanco de dados projetado.

Tabela 1.1 Objetivos de cada fase do ciclo de vida estruturado.

1111

H algumas vantagens em se adotar a metodologia estruturada, tais como: reduo de custos de desenvolvimento, implantao e manuteno, em funo da modularidade da metodologia; ganhos de produtividade, em funo do aumento da velocidade de desenvolvimento; possibilidade decompreenso do sistema por diferentes analistas e usurios; boa parte da documentao do sistema gerada a medida em que as atividades de desenvolvimento so realizadas; e a facilidade de manuteno, gerada pela possibilidade de ir direto ao ponto que precisa ser mudado, uma vez que as tcnicas empregadas geram uma documentao eficiente e eficaz.

Dentre as caractersticas das metodologias estruturadas, destacam-se: particionamento (quebra da complexidade do sistema em mdulos); funcionalidade (a anlise feita por funo do sistema); abordagem top-down (partindo do geral para o especfico); nfase modelagem conceitual ou lgica em relao fsica (destaca-se o funcionamento do sistema e no quem executa e onde so executadas as funes do sistema); e ordenamento das questes por qu?, o qu? e como (parte da definio dos objetivos, passando pelas funes, at chegar na lgica dos processos).

Outros ciclos de vidas esto disponveis na literatura sobre Engenharia de Software, particularmenteno livro Engenharia de Software, de Roger S. Pressman, tais como ciclo de vida da prototipao; ciclo de vida em espiral de Boehm; dentre outros.

Concluindo, uma Metodologia de Desenvolvimento de Sistemas apresenta vrios elementos como resultado, a partir da execuo das fase de seu ciclo de vida. Estes elementos esto descritos na Tabela 1.2.

Tcnicas Estruturadas

Segundo James Martin e Carma McClure, em seu livro Tcnicas Estruturadas e CASE (Ed. MakronBooks, 1991), as tcnicas estruturadas representam uma busca de disciplina na anlise de sistemas e programao. Com o desenvolvimento da metodologia estruturada, estas tcnicas trouxeram uma melhora significativa na qualidade dos programas, alm de tornar as atividades de anlise e programao um pouco mais previsveis.

Os principais objetivos das tcnicas estruturadas, segundo Martin e McClure so: construir programas de alta qualidade que tenham comportamento previsvel; construir programas que sejam facilmente modificveis; simplificar os programas e o seu processo de desenvolvimento; conseguir maior previsibilidade e controle no processo de desenvolvimento; acelerar o desenvolvimento de sistemas; e diminuir o custo do desenvolvimento de sistemas.

Martin e McClure definem, tambm, as caractersticas que consideram importantes nas tcnicas estruturadas: devem ser de fcil uso; devem ser usadas diretamente com as linguagens de quarta gerao ou geradores de cdigo; devem ser to rigorosas quanto possvel; devem ser orientadas para banco de dados; e devem ser projetadas para operar com ferramentas automatizadas.

Os autores completam sua anlise sobre tcnicas estruturadas, atravs da definio de princpios, que se dividem em: princpios bsicos da filosofia estruturada; outros princpios da Engenharia de

1212

Software; princpios da Engenharia da Informao; princpios de projetos de sistemas apoiados por computador; e princpios do envolvimento do usurio. A seguir descreveremos estes princpios.

1. Elementos relativos aos procedimentos gerenciais e organizao do desenvolvimento: solicitao do sistema pelo usurio / pela organizao; justificativa (problemas / oportunidades / necessidades atuais dos usurios ou da organizao); misso e objetivos de negcio do sistema; recursos disponveis e necessrios; restries; riscos; limites (escopo / abrangncia); anlise custo x benefcio; alternativas de projeto; plano de projeto de software; relatrio de acompanhamento / progresso; estimativas / mtricas; alocao de pessoal; soluo de implementao (desenvolvimento / aquisio); estratgia de desenvolvimento (lgica / impacto / tecnologia / metodologia); avaliao de pacotes; padres de projeto; padres de acesso fsico de programas a banco de dados / arquivos; manuais do sistema (procedimentos informatizados e no informatizados); estimativas fsicas de armazenamento de dados; estimativas de carga de processamento do sistema; aceitao do sistema pelo usurio / pela organizao.2. Elementos relativos aos requisitos do sistema: documentao / funcionamento do sistema atual; requisitos do sistema (necessidades do usurio / ambiente do sistema); requisitos de desempenho; requisitos de controle (segurana / integridade / auditoria / recuperao); requisitos de hardware / software / rede (comunicao de dados); requisitos de armazenamento de dados; requisitos ambientais dos locais do sistema; entradas e sadas do sistema.3. Elementos relativos modelagem do sistema: modelo fsico do sistema (processos e dados / atual e proposto); modelo conceitual do sistema (processos e dados); interfaces do sistema (integrao com outros sistemas / integrao da parte manual com a parte informatizada); modelo funcional do sistema (processos e dados); fluxo de tarefas do sistema; projeto de programas (lgica); projeto de banco de dados / arquivos; projeto de interface do sistema e fatores humanos (procedimentos / modelos).4. Elementos relativos s estratgias de desenvolvimento: estratgia de converso de dados; estratgia de testes; estratgia de treinamento; estratgia de cpia de segurana / recuperao / reorganizao de banco de dados e arquivos; estratgia de aquisio e instalao de hardware / software / rede; estratgia de manuteno do sistema.

Tabela 1.2 Elementos de uma Metodologia de Desenvolvimento de Sistemas.

1313

Princpios bsicos da filosofia estruturada

.Princpio da abstrao: para resolver um problema, deve-se separar os aspectos que esto ligados a uma realidade particular, visando represent-lo de forma simplificada e geral..Princpio da formalidade: deve-se seguir uma abordagem rigorosa e metdica para resolver um problema..Conceito de dividir para conquistar: deve-se resolver um problema difcil, dividindo-o em um conjunto de problemas menores e independentes que so mais fceis de serem compreendidos e resolvidos..Conceito de organizao hierrquica: deve-se organizar os componentes de uma soluo em uma estrutura hierrquica tipo rvore, de forma que ela possa ser compreendida e construda nvel por nvel, onde em cada novo nvel acrescenta-se mais detalhes.

Outros princpios da Engenharia de Software

.Princpio da ocultao de informaes: deve-se ocultar informaes no-essenciais, permitindo que o mdulo veja apenas a informao necessria quele mdulo..Princpio da localizao: deve-se colocar juntos os itens relacionados logicamente..Princpio da integridade conceitual: deve-se seguir uma filosofia e arquitetura de projeto coerentes..Princpio da completeza: deve-se checar tudo para garantir que nada foi omitido..Princpio da independncia lgica: na anlise e no projeto, deve-se concentrar a ateno nas funes lgicas, para que sejam realizadas independentemente da implantao fsica.

Princpios da Engenharia da Informao

.Princpio da anlise rigorosa dos dados: os dados tm uma estrutura prpria e a anlise de dados, que identifica formalmente esta estrutura, deve ser feita antes de o processo lgico ser projetado..Princpio da independncia dos dados: os modelos de dados, representando a estrutura lgica prpria dos dados, devem ser projetados formalmente, independentemente da utilizao da estrutura fsica e da distribuio dos dados..Princpio do planejamento estratgico dos dados: os dados requerem planejamento, definio e estruturao por toda a empresa, para que possam ser compartilhados entre processos..Princpio do acesso pelo usurio final: os usurios finais devem receber ferramentas que eles mesmos possam usar, sem programao, para ter acesso aos bancos de dados..Princpio da modelagem corporativa: os modelos de dados e modelos de processos so construdos em alto nvel da empresa (ou da maior diviso de uma empresa) de tal forma que sistemas desenvolvidos independentemente ajustem-se a essa estrutura e trabalhem em conjunto.

Princpios de projetos de sistemas apoiados por computador

.Tcnicas poderosas de projeto necessitam de automao: o crebro humano muito limitado em sua capacidade de lidar com detalhes, complexidades, rigor matemtico e ampla checagem cruzada sem cometer erros (o computador permite que os projetistas ultrapassem as fronteiras do crebro humano)..Projeto apoiado por computador requer grficos: todas as anlises e projetos estruturados utilizam-se de grficos e os diagramas tornam-se complexos e consomem muito tempo para serem modificados, necessitando de refinamento constante (uma ferramenta computadorizada facilita a construo,

1414

modificao, refinamento, expanso e extrao de sub-conjuntos dos diagramas do projeto, possibilitando o tratamento da complexidade)..A ferramenta computadorizada deve orientar o usurio: as ferramentas CASE (Computer AidedSoftware Engineering Engenharia de Softrware auxiliada por computador) devem incorporar as metodologias e orientar o projetista atravs de etapas que reflitam um bom projeto, solicitando informaes a partir do qual gerar o cdigo..Deve ser evitada a programao, sempre que possvel: os diagramas de projeto devem ser decomponveis, sucessivamente, em mais detalhes, at o cdigo poder ser gerado automaticamente..Devem ser utilizadas estruturas bsicas que resultem em projetos demonstrveis automaticamente: conveniente que se atinja um rigor bem maior do que aquele fornecido pelas tcnicas estruturadas atualmente conhecidas, priorizando as estruturas bsicas que resultem em automao matematicamente rigorosa do projeto..As linguagens devem ser feitas sob medida para as tcnicas de projeto: as novas linguagens de programao esto evoluindo rapidamente e devem empregar estruturas bsicas apropriadas, de forma que as melhores tcnicas para projeto automatizado estejam refletidas na linguagem.

Princpios do envolvimento do usurio

.Os usurios finais devem ter total envolvimento na anlise, projeto e administrao de dados: os usurios devem ser capazes de checar, a cada etapa, o que est sendo planejado e construdo para eles..As tcnicas estruturadas devem ser projetadas para aumentar a compreenso e a criatividade do usurio: os usurios devem ser capazes de esboar procedimentos que os ajudem a ler, discutir e modificar os esboos dos analistas, requerendo tcnicas estruturadas fceis de usar..Esboos de fcil uso devem ser diretamente decompostos em projetos integralmente precisos: os esboos, que so de fcil entendimento, devem ser extensveis, atravs de uma ferramenta computadorizada, para formar uma representao precisa, projetada para verificao axiomtica to completa e abrangente quanto possvel..Prottipos devem ser construdos, sempre que possvel: a realidade deve ser testada o mais cedo possvel em todos os sistemas..Ferramentas para usurios finais devem ser usadas, sempre que possvel: as ferramentas para os usurios finais, inclusive linguagens de consulta, geradores de relatrios, manipulao de planilhas e geradores de aplicao, devem ser utilizadas para permitir a mxima flexibilidade e para criar prottipos.

1515

Referncias Bibliogrficas

FOURNIER, A. Guia Prtico para Manuteno e Desenvolvimento do Sistemas Estruturados, Makron Books, 1994.

GANE, C. e SARSON, T. Anlise Estruturada de Sistemas, Editora LTC, 1983.

MARTIN, J.; McClure, C. Tcnicas Estruturadas e CASE, Makron Books, 1991.

PRESSMAN, R. S. Engenharia de Software,Makron Books, 3 Edio, 1995.

YOURDON, E. Anlise Estruturada Moderna, Editora Campus, 1992.

1717

Levantamento de DadosLevantamento de Dados22


TTcnicas de levantamento decnicas de levantamento deDadosDados

EntrevistasEntrevistas

DocumentaDocumentao dos requisitoso dos requisitosdo sistemado sistema

Levantamento de dados o processo que permite coletar os requisitos do sistema, visando sua anlise.

As principais tcnicas de levantamento de dados so: entrevistas, questionrios, anlise de documentao, anlise de observao, demonstrao feita por fornecedores, visitas a outras instituies, sesses informais de braimstorming em grupo. A tcnica mais utilizada a entrevista.

Objetivos da entrevista

Os objetivos da entrevista so: coletar informaes sobre o comportamento de um sistema atual ou sobre os requisitos de um novo sistema verificar a compreenso adquirida sobre o comportamento

de um sistema atual ou sobre os requisitos de um novo sistema; e coletar informaes para os estudos de viabilidade.

Alguns cuidados especiais devem ser tomados durante a entrevista: normalmente, o usurio concentra-se nos sintomas dos problemas, em vez de se ocupar com as causas reais; o usurio expressa suas necessidades em termos de solues informatizadas predeterminadas sem entender a natureza real do problema, assumindo hipteses falsas sobre solues informatizadas; podem existir algumas disparidades entre a verso oficial de como um sistema manual existente e um procedimento automatizado devem funcionar e o que realmente ocorre em nvel operacional.

do ponto de vista do entrevistador , os seguintes objetivos devem ser atingidos: examinar a emotividade da pessoa entrevistada, seus anseios, tendncias, atitudes, preferncias e

motivaes; ouvir um relato, biogrfico ou cronolgico, de fatos vivenciados ou observados pelo entrevistado; utilizar a entrevista para coordenar informaes recebidas de fontes diversas, podendo apreciar o entrevistado em seu conjunto.

Para atingir seus objetivos, o entrevistador dever estar atento, antes da entrevista: s caractersticas inerentes do entrevistado, sua satisfao emocional e intelectual; aos aspectos de tempo, assunto e nvel de profundidade da entrevista, s exigncias que esta ter do entrevistado; s experincias anteriores do entrevistado, e sua qualificao para influir no processo de reordenao dos fatos.

Para se obter bons resultados, as seguintes capacidades devem ser desenvolvidas: capacidade de ser um observador atento; capacidade para deixar o entrevistado vontade; capacidade de encadeamento de assuntos. A imagem transmitida anteriormente ao entrevistado deve ser preservada, bem como a postura adotada frente a esta situao. No basta ter credibilidade, necessrio mostr-la.

Diretrizes para a entrevista

Antes da entrevista, as seguintes diretrizes devem ser seguidas: identifique, das reas envolvidas com o sistema, representantes que possam contribuir com informaes acerca do sistema; desenvolva um plano geral de entrevistas; elimine preconceitos para evitar transmiti-los durante o contato com o entrevistado; evite basear-se em opinies de outras pessoas; evite demonstrar preferncias por certo tipo fsico; evite pensar que experincias anteriores so garantias de habilidade futura; no externe sua opinio no trato de questes polmicas, para no gerar conflitos e um clima desfavorvel na entrevista; identifique a posio e as responsabilidades atuais do entrevistado; obtenha o mximo de informaes pertinentes sobre as funes executadas na rea do entrevistado, incluindo formulrios e exemplos de relatrios apropriados; certifique-se que voc tem autorizao para agendar entrevistas com os usurios identificados; marque um horrio para conversar com o usurio, de preferncia em um local em que no haja interrupes, nem distraes em potencial; marque a entrevista para um horrio que seja conveniente ao usurio; planeje a entrevista para fazer uso eficiente do tempo; tente descobrir que informaes o usurio est mais interessado; prepare a entrevista, listando pontos sobre os quais voc considera importante ter informaes sobre o sistema; sempre que possvel, prepare um esboo da entrevista e passe cpia para o entrevistado.

Durante a entrevista, deve-se atentar para as seguintes diretrizes: seja pontual e respeite o tempo determinado para a entrevista; use um estilo adequado de entrevistar; inicie se apresentando e expondo os objetivos da entrevista; explique os motivos pelos quais o interlocutor foi escolhido para ser entrevistado; comece fazendo perguntas de livre contexto (conjunto de perguntas que leve a uma compreenso bsica do problema, s pessoas que querem uma soluo, natureza da soluo que desejada e efetividade do primeiro encontro em si); evite desvios do assunto; separe funcionalidade de implementao; procure obter uma viso geral do sistema antes de aprofundar-se em questes especficas; faa "ganchos", articulando as questes seguintes s respostas dadas pelo usurio, quando houver algum relacionamento; faa a distino entre fatos e opinies; faa anotaes das respostas dadas pelo usurio e explique ao entrevistado porque est fazendo isto; se

1818

for gravar ou filmar a entrevista, pea autorizao ao usurio antes de comear e informe o objetivo de fazer a gravao; associe a cada requisito as suas restries, se houver; se pretende faz-lo, pea permisso para falar posteriormente com a equipe do entrevistado; no demore mais do que 2 horas numa entrevista (se for necessrio planeje outras); explique que todas as informaes obtidas durante a entrevista sero submetidas sua aprovao antes de sua publicao oficial; perto do final da entrevista, resuma os principais pontos discutidos para confirmar que entendeu o que foi dito; encerre a entrevista com uma observao positiva, agradecendo ao entrevistado por sua contribuio.

Sobre as perguntas de livre contexto, algumas recomendaes importantes so: o primeiro conjunto de perguntas concentra-se no cliente, nas metas globais e nos benefcios; o conjunto de perguntas seguinte capacita o analista a obter uma melhor compreenso do problema e o cliente a verbalizar suas percepes sobre uma soluo; o conjunto seguinte de perguntas concentra-se na efetividade do encontro (metaperguntas).

Aps a entrevista, as seguintes diretrizes devem ser seguidas: documente todos os pontos relevantes obtidos durante a entrevista; envie a documentao ao entrevistado para obter observaes e aprovao final; se for necessrio um esclarecimento posterior, contate o entrevistado para marcar outra reunio; envie os resultados para os usurios e seus gerentes.

Documentao dos requisitos do sistema

Os requisitos do sistema devem ser documentados, preferencialmente de forma direta e objetiva (cada requisito deveria ser escrito em uma frase). A documentao dos requisitos pode ser feita em um formulrio, como apresentado na Figura 2.1.

1919

Figura 2.1. Modelo de documentao de requisitos do sistema.


FELICIANO NETO, A.; FURLAN, J. D.; HIGA, W. Engenharia da Informao, Editora McGrawHill, 1988.


2020

2121

Diagrama de Fluxo de DadosDiagrama de Fluxo de Dados(DFD)(DFD)33


Elementos do DFDElementos do DFD

Diagrama de ContextoDiagrama de Contexto

NNveis do DFDveis do DFD

NotaNotao gro grfica do DFDfica do DFD

PrincPrincpios para a elaborapios para a elaborao doo doDFDDFD

Sintaxe do DFDSintaxe do DFD

Dentre as tcnicas estruturadas para anlise orientada a processos, o Diagrama de Fluxo de Dados (DFD) , com certeza, a mais clssica e a mais utilizada. A histria da Anlise Estruturada, como Metodologia de Desenvolvimento de Sistemas, se confunde com a do Diagrama de Fluxo de Dados, pois esta tcnica caracteriza todo o desenvolvimento estruturado de sistemas.

Este captulo pretende trazer os conceitos e notaes relativos ao Diagrama de Fluxo de Dados, principalmente na viso dos grandes autores relacionados Anlise Estruturada: Tom DeMarco; Chris Gane & Trish Sarson; e Eduard Yourdon.

Consideraes iniciais

O Diagrama de Fluxo de Dados uma ferramenta para modelagem de fluxo de dados, atravs darepresentao de processos que usam e geram dados. Tom DeMarco, um dos primeiros autores sobre Diagrama de Fluxo de Dados, define o DFD como sendo uma representao em rede de um sistema (...) que (...) pode ser automatizado, manual ou misto. O Diagrama de Fluxo de Dados retrata o sistema em termos de suas partes componentes, com todas as interfaces entre os componentes indicadas" (Anlise Estruturada e Especificao de Sistemas, Ed. Campus, 1989).

Edward Yourdon, define o DFD como uma ferramenta de modelagem que nos permite imaginar um sistema como uma rede de processos funcionais, interligados por dutos e tanques de armazenamento de dados (Anlise Estruturada Moderna, Ed. Campus, 1990).

O DFD um dos principais componentes da chamada especificao estruturada. No ciclo de vida estruturado, a fase de anlise do sistema consiste em transformar os requisitos do usurio

2222

em especificao estruturada. Os requisitos do sistema incluem as necessidades do usurio (o que ele precisa do sistema para que seus objetivos sejam atingidos) e o ambiente do sistema (como o sistema funciona, seus problemas e suas oportunidades). Os requisitos do sistema so obtidos pelo analista de sistemas atravs de tcnicas de levantamento de dados, das quais a mais utilizada e aplicada na maioria dos casos a entrevista. O analista de sistemas entrevista os usurios do sistema para compreender os seus requisitos e os documenta, ainda que de forma textual, para que estes requisitos sirvam de base para uma das principais tarefas do ciclo de vida do desenvolvimento do software que a anlise. Na anlise, os requisitos so transformados em especificao estruturada, que composta basicamente pelo Diagrama de Fluxo de Dados, pelo Dicionrio de Dados, pelo Diagrama Entidade-Relacionamento, pelo Diagrama de Descrio de Entidades e pelas Especificaes de Processos (em Portugus Estruturado, Tabela de Deciso ou rvore de Deciso). A especificao estruturada a documentao da anlise feita pelo analista ou grupo de analistas junto com os usurios, onde o sistema visto em termos conceituais e funcionais (e, s vezes, at em termos fsicos do sistema atual), e todos os componentes, que precisam ser conhecidos e representados sem ambigidade, omisso ou redundncia, so modelados para que o projeto do sistema possa ser feito.

O DFD possui apenas quatro elementos que so necessrios e suficientes para modelar o sistema em termos conceituais e funcionais. Estes elementos so:Entidade externa (chamada assim por Gane & Sarson e chamada de terminador, por Yourdon, ou por ponto terminal, por Martin & McClure, ou ainda de fontes e destinos de dados, por DeMarco): de onde partem ou para onde chegam os dados (origem e destino);Fluxo de dados: indicam os dados e o caminho por onde percorrem no sistema;Processo ou funo: ponto de processamento dos dados (tratamento, alterao ou manuseio de dados);Depsito de dados (assim chamado por Gane & Sarson e Martin & McClure e chamada de depsito, por Yourdon, ou arquivo, por DeMarco): indica qualquer tipo de armazenamento de dados.

A representao atravs de um DFD feita em nveis ou camadas, partindo-se sempre de uma viso mais global para a viso mais detalhada ou especfica. Esta abordagem chamada de top-down.

As vantagens de utilizar o Diagrama de Fluxo de Dados para modelagem de sistemas so vrias, dentre elas podemos citar:Representar o sistema atravs de um DFD uma maneira sistemtica de definio e especificao;DFD uma especificao que possui algum formalismo, tal como proposto nos princpios da Engenharia de Software;DFD permite registrar as necessidades e preferncias do usurio;DFD permite uma viso grfica do problema, evitando as ambigidades, redundncias e omisses prprias de uma especificao narrativa;A utilizao do DFD permite que o mesmo instrumento de anlise sirva tambm de documentao;uso de DFD facilita o controle de projeto.

2323

Smbolos do DFD

A notao do DFD grfica e utiliza um smbolo para cada um dos quatro elementos que compem o diagrama. A Figura 3.1 mostra estes smbolos nas duas verses mais utilizadas para se desenhar Diagramas de Fluxo de Dados. Por uma questo de padronizao, a notao a ser utilizada na disciplina Anlise e Projeto Estruturado a proposta por Yourdon e DeMarco. Na realidade, as duas notaes atendem sintaxe do DFD, no havendo, portanto, uma que seja melhor do que a outra. A notao proposta por Gane & Sarson mais difcil de fazer modurante os primeiros momentos de definio, mas, em compensao, mais fcil de ser feito no computador. A notao de Yourdon e DeMarco facilmente feita mo e mais difcil de ser computadorizada.

Figura 3.1. Smbolos do Diagrama de Fluxo de Dados.

As entidades externas so, geralmente, categorias lgicas de coisas ou pessoas que representam uma fonte ou destino para as transaes. Exemplos: cliente, empregado, fornecedor, contribuinte, segurado, etc. Elas tambm podem ser uma fonte ou destino especfico, como: Departamento de Contas, Receita Federal, Escritrio do Presidente, etc. Quando o sistema enfocado recebe dados de um outro sistema ou fornece dados a ele, aquele outro sistema considerado entidade externa. Ao identificar alguma coisa ou sistema como entidade externa, estar sendo afirmado, implicitamente, que esta entidade est fora dos limites do sistema considerado.

O fluxo de dados pode ser considerado como um tubo por onde passam pacotes de dados. Os fluxos de dados so os nicos elementos de ligao de um DFD. Isto significa que os outros elementos podem ligar-se entre si, a no ser que seja atravs de um fluxo de dados. Quando mais de um elemento de dados tem a mesma origem e o mesmo destino, eles podem ser representados por um nico fluxo de dados, separando-se seus nomes pelo conector +. Por exemplo, se um cliente deve apresentar, a um sistema de vendas, seu nome e seu nmero do RG, esta representao pode ser feita num nico fluxo de dados, com o nome nome do cliente + rg.

2424

Os processos so definidos atravs de um identificador e um nome significativo. O identificador geralmente um nmero, que tem como nico propsito identificar o processo. Isto significa que o nmero atribudo como identificador no deve se repetir e no indica ordem ou seqncia de execuo. No h razo para associar significados a nmeros de processos, pois alguns deles sero subdivididos em dois ou mais processos (o que significa que novos nmeros surgiro) ou que vrios processos sero agrupados em um nico (significando que alguns nmeros desaparecero), no decorrer do trabalho de anlise. A partir do momento em que o processo recebe a identificao, esta no deve ser modificada, exceto para desmembramentos ou agrupamentos, pois serve como referncia para os fluxos de dados e para decomposio do processo em nveis inferiores. A descrio da funo deve ser um sentena imperativa, constituda por um verbo ativo no infinitivo seguido de um objeto direto. Esta sentena deve ser a mais simples possvel, como: extrair vendas mensais; dar entrada de detalhes do novo cliente, averiguar se cliente tem crdito, etc. Deve ser observado que, nestas frases, o sujeito indeterminado. No momento em que um sujeito for introduzido, h um compromisso fsico sobre o desempenho da funo, o que pode ser til quando estuda-se um sistema existente para denotar o departamento, ou o programa, que desempenha uma funo. De forma semelhante, quando a anlise est completa e o projeto fsico do novo sistema estsendo desenvolvido, conveniente observar como a funo ser fisicamente desempenhada.

Os depsitos de dados indicam armazenamento, sem o compromisso quanto ao aspecto fsico (se em computador, arquivo de uma sala, ou uma gaveta, por exemplo). Durante a anlise, so detectados certos lugares onde haver dados armazenados entre processos. Quando um processo armazena dados, a seta do fluxo de dados aponta para o depsito de dados; por outro lado, quando um processo efetua acesso a dados armazenados em um depsito (em forma de leitura), a representao feita com a seta do fluxo de dados apontada para o processo e o nome do fluxo de dados englobando o grupo de elementos de dados que est sendo recuperado pelo processo.

Sintaxe do DFD

Ao se desenhar um Diagrama de Fluxo de Dados, algumas regras devem ser seguidas para que sejam vlidas as especificaes geradas pelo grfico. Estas regras so as seguintes:

1. Todos os objetos do DFD devem ter identificadores. Entende-se por objetos do DFD as entidades externas, os processos e os depsitos de dados. Cada entidade externa deve ter um identificador representado por uma letra minscula no canto superior esquerdo do smbolo (na notao de Yourdon e DeMarco, o identificador de entidade externa pode ser omitido). Os processos so identificados por nmeros, de acordo com o nvel de detalhamento que representam. Os depsitos de dados so identificados apenas pela notao de Gane & Sarson e os identificadores devem respeitar o formato Dx, onde x um nmero seqencial usado para identificar o depsito.

2. Todos os objetos e fluxos de dados do DFD devem ter nome. Os quatro elementos do DFD devem ter nomes significativos. Os nomes dos fluxos de dados devem ser escritos com todas as letras em minsculo. Os nomes dos processos devem comear com letra maiscula e as demais letras minsculas. As entidades externas devem ter seus nomes escritos com todas as letras em maisculo

2525

ou pela primeira em maisculo e as demais em minsculo. Os nomes das entidades externas geralmente so representados no singular. Os depsitos de dados tm seus nomes representando plural ou coletivo e devem comear com letra maiscula e as demais em minsculo (em algumas notaes, aceita-se utilizar todas as letras maisculas para nome de depsito de dados).

3. Todos os processos devem ter pelo menos um fluxo de dados de entrada e um de sada. Os processos representam funes que so executadas sobre dados de entrada, transformando-os em dados de sada. Neste sentido, no possvel ter em um DFD processos do tipo gerao espontnea, onde no h nenhum fluxo de dados de entrada e um ou mais de sada. Tambm no permitido processo do tipo buraco negro, que consiste em um ou mais fluxos de dados de entrada, sem gerar nenhum dado de sada.

4. Todos os fluxos de dados devem ter uma origem e um destino. Cada fluxo de dados deve ser gerado por um processo, entidade externa ou depsito de dados. Igualmente, todos os fluxos de dados devem ser usados por um processo, entidade externa ou depsito de dados. Portanto, no permitido, no DFD, um fluxo de dados que comece no nada e v para algum objeto do DFD, bem como um fluxo de dados que seja gerado por um objeto do DFD e vai para o nada.

5. Todos os fluxos de dados devem comear ou terminar num processo. No deve existir, no DFD, ligao entre dois depsitos de dados ou duas entidades externas ou, ainda, entre um depsito de dados e uma entidade externa, sem que haja um processo no meio para fazer esta ligao. Isto ocorre em funo de que as aes do DFD so, todas elas, executadas pelos processos. Um fluxo de dados no tem a capacidade de mover-se sozinho no sistema. H sempre a necessidade de um processo envi-lo para algum lugar ou peg-lo de algum lugar. possvel, porm, haver um fluxo de dados cuja origem seja um processo e o destino, outro processo.

6. Todos os fluxos de dados devem ter uma nica seta direcional. Um fluxo de dados caracteriza-se por uma nica origem e um nico destino. Portanto, nos casos em que a interface entre um objeto qualquer e um processo seja um mesmo dado que entra e que sai do processo, este dado deve ser representado em dois fluxos de dados, um em cada sentido.

7. Todos os objetos e fluxos de dados devem ter nomes significativos. Nome significativo quer dizer um nome relevante para o sistema. Como regras para a formao de nomes, deve-se respeitar: para entidade externa, o nome deve estar no singular; para depsito de dados, o nome deve estar no plural; para fluxo de dados, o nome no deve indicar ao, no contendo verbo em seu incio; para processo, o nome deve representar ao, comeando, portanto, com verbo. Os processos devem ter seu nome formado por verbo no infinitivo + objeto de direto.

8. Todos os depsitos de dados devem representar objetos de interesse para o sistema. Depsitos de dados somente de leitura ou somente de escrita devem ser bem avaliados, pois podem significar algum armazenamento de dados fora do contexto do sistema.

9. .A duplicao de smbolos e o cruzamento deve ser evitado. O desenho do DFD deve ser feito de forma a evitar a necessidade de representar um mesmo objeto duas vezes ou cruzar linhas para fazer as ligaes entre os objetos. Quando no for possvel, deve-se minimizar o uso destes recursos e,

2626

assim mesmo, tomar algumas providncias. Se for necessrio duplicar uma entidade externa, deve-se marc-la com uma linha inclinada no canto inferior direito (formando uma espcie de tringulo na extremidade inferior direita do smbolo da entidade), para cada repetio. Se for necessrio duplicar um depsito de dados, na notao de Gane & Sarson, deve-se acrescentar uma linha vertical entre o identificador e o nome do depsito para cada repetio que ocorrer. No caso de haver cruzamento de linhas (fluxos de dados), deve-se usar a estratgia de fazer um arco no cruzamento, como se um fluxo estivesse passando por cima do outro, ou uma fenda, deixando um pequeno espao em branco nas proximidades do cruzamento, dando a impresso de que o fluxo de dados est passando por baixo do outro.

Nveis de representao do DFD tcnicas de fracionamento da complexidade e expanso

Um DFD pode ser desenhado em vrios nveis, dependendo da complexidade e grau de detalhamento do

sistema. Pelo menos dois nveis ocorrem em qualquer sistema: o Diagrama de Contexto e o DFD nvel 0.

Primeiramente, o sistema modelado em termos de suas entradas e sadas de dados e as origens e destinos destes dados. Esta modelagem chamada de Diagrama de Contexto e representa o sistema como sendo um nico processo que troca informaes com as entidades externas, sem representar os depsitos de dados do sistema.

Em seguida, feita uma decomposio do Diagrama de Contexto em um DFD que mantm a coerncia com o Diagrama de Contexto, ou seja, mantm as mesmas entradas e sadas e as mesmas origens e destinos de cada dado. Porm, neste novo nvel, chamado de DFD nvel 0, acrescentado o detalhamento dos processos, que operam sobre os fluxos de dados, e os depsitos de dados, que representam o armazenamento de dados. Neste nvel, novos fluxos de dados intermedirios podem surgir, desde que mantenha a coerncia com o Diagrama de Contexto. Os depsitos de dados so criados, no DFD nvel 0, sempre que dados so armazenados para uso posterior ou quando no hseqncia imediata na execuo de dois processos, onde um gera uma informao que usada pelo segundo.

O detalhamento de processos do DFD nvel 0 se d no nvel 1. Ao DFD nvel aplica-se as mesmas regras do DFD nvel 0. Porm, sua representao restringe-se ao detalhamento de um determinado processo daquele diagrama, apresentando coerncia com o contexto daquel nvel, ou seja, mesmas relaes de entrada e sada e origens e destinos de dados representados no nvel 0.

O detalhamento de processos do DFD nvel 1 se d no nvel 2, da mesma forma. E assim sucessivamente, toda vez que um processo necessitar de detalhamento, este feito no nvel seguinte. importante destacar que, no Diagrama de Contexto, o nico processo representado significa o sistema em foco. Portanto, no aplica-se, a este diagrama, a necessidade de que o processo tenha um identificador e de que o nome seja formado por verbo, pois o nome do processo representado no Diagrama de Contexto o nome do prprio sistema.

2727

A aplicao dessas tcnicas de nivelamento permite um fracionamento da complexidade de sistemas grandes, bem como a expanso da compreenso de sistemas que so construdos na abordagem top-down, uma vez que possvel ir detalhando cada vez mais o funcionamento do sistema, tendo como ponto de partida uma viso geral das principais funes do mesmo.

importante ter em mente que cada processo no nvel superior do DFD de um sistema pode ser expandido ou explodido para tornar-se um novo diagrama. Cada processo no nvel inferior tem que se relacionar com o processo de nvel superior. dado um nmero de identificao ao processo de nveis mais baixos, onde este nmero um valor decimal do processo de nvel superior, isto , o processo 4, do DFD nvel 0, decomposto em 4.1, 4.2, 4.3, etc., no DFD nvel 1, e, se for necessrio um maior detalhamento, o processo 4.2, por exemplo, pode ser decomposto nos processos 4.2.1, 4.2.2, etc., no DFD nvel 2, e assim por diante.

A maneira mais clara de representar o processo de expanso desenhar DFDs de menor nvel dentro da divisa que representa o smbolo do processo de nvel superior. bvio que todos os fluxos de dados que entram e saem do processo de maior nvel devem entrar e sair da divisa. Os depsitos de dados s so mostrados dentro da divisa quando so criados e processos apenas por este processo.

Diretrizes para desenhar um DFD

Pode-se considerar resumidamente que os passos envolvidos no projeto de um Diagrama de Fluxo de Dados para um sistema proposto ou j existente so os seguintes:

1. Identificar as entidades externas envolvidas. Isto envolve decidir sobre a fronteira ou divisa preliminar de um sistema. Quando houver dvida, deve-se incluir no sistema a primeira camadaexterna de sistemas manuais e automatizados, com a qual se ir lidar. Deve-se lembrar que fluxos de dados so criados quando alguma coisa ocorre no mundo externo, isto quando uma pessoa decide comprar algo, quando ocorre um acidente, ou um caminho chega ao ponto de carregamento. Se for possvel, o fluxo de dados deve iniciar-se na fonte bsica dos dados.

2. Desenhar o Diagrama de Contexto, identificando os dados que vm e vo para as entidades externas identificadas.

3. Identificar as entradas e sadas programadas que podem ser esperadas no curso normal dos negcios. medida que a lista aumenta, deve-se procurar descobrir agrupamentos lgicos de entradas e sadas. As entradas e sadas que esto associadas unicamente s condies de erro e exceo devem ser marcadas.

4. Identificar as consultas e os pedidos de informao que possam surgir. Devem ser especificados fluxos de dados que definam a informao dada ao sistema e aquela que diga o que requeridodo sistema.

2828

5. Pegar uma grande folha de papel e, comeando no canto esquerdo com a entidade externa que parece ser a principal fonte de entradas, desenhar os fluxos de dados que surgem, os processos logicamente necessrios e os depsitos de dados que paream necessrios.

6. Desenhar o primeiro esboo mo livre e concentrar-se em anotar tudo, exceto erros, excees e decises.

7. Aceitar o fato de que sero necessrios vrios esboos do DFD nvel 0. No deve haver preocupao se o primeiro esboo se parece mais com um novelo. Este pode ser desvencilhado.

8. Quando o primeiro esboo estiver pronto, verificar se todas as entradas e sadas listadas foram includas, exceto aquelas que tratam dos erros e excees. Deve-se observar, no esboo, quaisquer entradas e sadas normais que no puderam ser includas.

9. Produzir um segundo esboo mais claro, lembrando que o objetivo um diagrama com processos nicos e um nmero mnimo de interseces de fluxos de dados. Para minimizar os cruzamentos, primeiramente deve-se duplicar entidades externas, se necessrio. Em seguida, duplica-se os depsitos de dados, se necessrio. E, finalmente, se no houver uma forma de desenhar o diagrama sem que haja interseco de fluxo de dados, deve-se permitir que haja o desenho de cruzamentos. Deve-se verificar se ainda possvel um novo esboo que seja mais claro, alm de verificar, junto lista de entradas e sadas, se h algo que ainda no se tenha conseguido incluir.

10. Rever o segundo esboo com um representante do usurio que esteja disposto a colaborar, ou com algum que conhea a aplicao, explicando que apenas um esboo e anotando qualquer mudana resultante da reviso.

11. Produzir uma expanso de nvel inferior para cada processo definido no segundo esboo. Deve-se resolver o tratamento dos erros e excees e, se necessrio, incorporar as modificaes no diagrama de nvel superior.

Observao: se houver disponibilidade de ferramenta automatizada para desenhar o DFD, todas as verses

podem ser feitas atravs da ferramenta.


GANE, C. e SARSON, T. Anlise Estruturada de Sistemas, Editora LTC, 1983.

MARTIN, J.; McClure, C. Tcnicas Estruturadas e CASE, Makron Books, 1991.


2929

Exerccios

3.1. Faa o Diagrama de Contexto, o DFD nvel 0 e os DFDs de nveis mais detalhados (quando necessrios), para os requisitos abaixo:

O oramento da Cia. W controlado da seguinte maneira: a partir de uma proposta oramentria das filiais, e uma vez que todas as tenham entregue, feita uma consolidao, em nvel nacional, que servir de base para que os tcnicos de oramento possam estabelecer os dispndios a serem consumidos. Novas consolidaes so feitas, at que se conclua que o oramento est fechado. Os tetos assim fixados so enviados ento s filiais. Estas podero fazer revises de forma a adequar seu oramento nova realidade. A cada ms, as filiais tero que informar o realizado no perodo para que se possa efetuar o acompanhamento, que encaminhado aos tcnicos para anlise.


Os pacientes de um consultrio quando querem marcar uma consulta mdica, fazem pelo telefone ou indo pessoalmente secretria do mdico. Esta, por sua vez, cadastra os dados de identificao do paciente e efetua uma agenda com a distribuio de horrios disponveis. Quando o paciente chega para a consulta, entregue ao mdico uma ficha cadastral do paciente. Ao processar a consulta, que pode ser de primeira vez ou de retorno, o mdico pesquisa os sintomas, atravs de interrogatrio e pelo histrico de pacientes.


Uma organizao, com escritrios em vrios locais no pas, pretende realizar um concurso. Dada sua dimenso e expectativa de grande nmero de candidatos, ela deseja controlar todo o processo, desde a inscrio do candidato at a divulgao dos selecionados, com o desenvolvimento de um sistema informatizado. As provas sero realizadas nos locais onde a organizao possui filial, ficando sua aplicao sob a responsabilidade dos rgos regionais de seleo. Para cada local de prova so gerados nmeros de inscrio, que acompanharo o candidato durante todo o desenrolar do concurso. A qualquer momento, sempre que um rgo regional solicitar, o sistema deverpermitir geraes adicionais de nmeros de inscrio. O nmero de inscrio seqencial, dentro de cada local de prova, e gerado a partir de previses feitas por cada rgo regional, que estabelece as quantidades necessrias. Aos candidatos so fornecidos guias (recibos) de pagamento e fichas de inscrio, com nmeros j apropriados, para bancos autorizados. Diariamente, os bancos fornecem, organizao, os pagamentos efetuados. Uma vez recolhida a taxa, o candidato entrega a ficha de inscrio ao rgo regional. Uma inscrio s ser aceita no caso do candidato preencher todos os pr-requisitos estabelecidos pelo edital publicado, ter pago a taxa de inscrio, ter optado por um local de trabalho onde a organizao possua filial, alm, obviamente, de ter preenchida de forma correta todas as informaes necessrias. No caso de alguma irregularidade, a organizao tentarconvocar o candidato para que sejam efetuadas as devidas correes. A organizao no devolver a taxa de inscrio paga, na hiptese da inscrio no poder ser aceita. O concurso se dar em vrias fases, todas eliminatrias. Para qualquer uma delas, os rgos regionais devem receber uma lista de

3030

presena, para assinatura do candidato, juntamente com os nmeros de inscrio dos candidatos aptos par a fase, a serem apropriados s folhas de respostas. Cada prova ser corrigida a partir de um gabarito e dos pesos de cada questo, fornecidos por uma banca de professores encarregada da elaborao das provas. Ao final do concurso, a diretoria de recursos humanos fornecer critrios de seleo, como nmero de vagas por local, peso por prova, etc., que juntamente com as opes dos candidatos, serviro de base para a apurao dos resultados. A diretoria de recursos humanos estabelece esses critrios a partir de estatsticas a serem realizadas sobre o concurso.


A prefeitura de um municpio responsvel pela cobrana do servio de gua e esgoto na cidade. No incio do ms, um representante da prefeitura passa em todos os imveis da cidade fazendo a leitura dos hidrmetros. Esta leitura registrada e comparada com a leitura do ms anterior, com o objetivo de calcular a diferena de consumo e cobr-la do proprietrio atravs de um talo de cobrana, que registra os dados da ltima leitura. Quando o proprietrio efetua o pagamento, dado baixa no talo de cobrana correspondente a este pagamento.


Uma indstria possui seu departamento comercial dimensionado para efetuar vendas em vrias partes do pas. O cliente faz um pedido que identifica um produto em cada um de seus itens. feita uma checagem para verificar se o produto tem saldo. Se tiver saldo, emitida uma ordem de faturamento para o cliente, para que possa ser feito o pagamento correspondente ao pedido. Se no houver saldo, emitida uma ordem de fabricao correspondente ao produto para a fbrica. Neste caso, a fbrica ir enviar o produto acabado, para que possa ser confrontado com o pedido e, se estiver correto, ser gerada uma ordem de faturamento para o cliente que fez o pedido. Uma vez que o cliente faa o pagamento da ordem de fatura, dada baixa nesta ordem.


O funcionamento da rea de compras de uma empresa baseia-se na necessidade de materiais vindas do estoque atravs de uma solicitao de compra. A solicitao de compra emitida pelo estoque toda vez que um material requisitado, mas no tem saldo disponvel em estoque. De posse da solicitao de compra, o Setor de Compras verifica quais so os materiais solicitados e agrupa-os com outras solicitaes de compra j recebidas. Alm destas solicitaes, o Setor de Compras verifica o histrico das ltimas compras do mesmo material, realizando um planejamento de compra, em funo do consumo. Com base nessas anlises, o Setor de Compras emite o pedido de cotao, agrupando uma srie de solicitaes de compra. De posse do pedido de cotao, verificado quais so os possveis fornecedores deste material. Desta forma, verificado o histrico de cada um desses fornecedores e com base nisto realizada uma seleo de quais fornecedores recebero o pedido de cotao. Depois disto, o pedido de cotao enviado aos fornecedores

3131

selecionados. Quando os fornecedores informarem os preos e condies de pagamento solicitados no pedido de cotao, o Setor de Compras avalia as melhores opes, agrupa os materiais de acordo com estas opes e gera um ou mais pedidos de compra para o(s) fornecedor(es) que oferece(m) a melhor opo. Quando o Setor de Compras envia o pedido de compra para o fornecedor, uma cpia deste pedido enviado para o Setor de Recebimento de Materiais para que este possa conferir a remessa do fornecedor com o que foi solicitado. O Setor de Recebimento envia para o Setor de Compras um informe de chegada de materiais, quando recebe material do fornecedor de acordo com o pedido de compra, para que possa ser atualizado o pedido de compra e o histrico do fornecedor.


Uma fbrica de calados tem o funcionamento de seu sistema de vendas conforme a descrio a seguir. O Setor de Produo informa a previso de fabricao (quantidade de calados que estardisponvel para a venda em um determinado perodo) para que seja feita a distribuio de vendas. A distribuio de vendas leva em considerao todos os vendedores cadastrados, com seus respectivos histricos de vendas. Como resultado deste processo gerado um mapa de distribuio de produtos para venda que encaminhado ao Gerente de Vendas e arquivado para acompanhamento das vendas. O Gerente de Vendas, por sua vez, informa ao sistema os preos de cada produto, que so arquivados no cadastro de produtos. Para cada venda efetuada por um vendedor, este informa ao sistema a quantidade vendida e o produto. Com base nestas informaes e no cadastro do produto, calculado o valor da comisso do vendedor, que informado Tesouraria, e a venda atualizada no histrico do vendedor. Mensalmente, a Tesouraria informa o valor total das comisses de cada vendedor, para que o sistema emita um relatrio para cada vendedor.


Quando o fornecedor envia um ou mais materiais para a empresa, ele envia, tambm, uma nota fiscal discriminando estes materiais. O Setor de Recebimento confere os materiais com a nota fiscal e, se no estiver correto, devolve-os ao fornecedor. Caso os materiais estejam corretamente discriminados na nota fiscal, feita a conferncia com o pedido de compra que foi enviada peloSetor de Compras ao fornecedor. Se no estiver correta, gerada uma notificao de divergncia de compra, identificando a nota fiscal recebida e o pedido de compra relativo ao recebimento, e enviada ao fornecedor. Caso os materiais recebidos estejam de acordo com o pedido de compra, gerada uma nota de recebimento de materiais que enviada para o Kardex atualizar o saldo do material. Outra via da nota de recebimento de materiais enviada para o Setor de Contas a Pagar. Quando algum centro de custo da empresa necessidade de material, preenchida uma requisio de materiais que levada ao Almoxarifado, onde feita a conferncia se existe saldo ou no dos materiais solicitados em estoque. Se houver saldo suficiente, os materiais so entregues para o solicitante e a requisio de materiais vai para o Kardex, para atualizao do saldo em estoque, e outra via para o Setor de Custos. Caso algum material no tenha saldo, gerada uma solicitao de compras que vai para o Setor de Compras. O Setor de Compras encarrega-se de agrupar as solicitaes de compra, gerando o pedido de compra. Quando algum centro de custo no utiliza todo

3232

o material que foi requisitado atravs da requisio de materiais, o material que sobrou devolvido ao Almoxarifado, juntamente com uma nota de devoluo de materiais ao estoque. O almoxarife confere a quantidade e o tipo do material devolvido com o especificado na nota de devoluo de materiais ao estoque. Se no estiver correto, tanto os materiais como a nota de devoluo de materiais ao estoque so recusados e retornam ao centro de custo que os enviou. Se estiver correto, a nota de devoluo de materiais ao estoque enviada para o Kardex, para atualizao do saldo dos materiais, e outra via para o Setor de Custos.


O reitor de uma universidade decidiu unificar as operaes de todas as bibliotecas existentes nas vrias unidades da universidade. Cada biblioteca mantm as informaes sobre os livros e peridicos (ou seja, as referncias) de seu acervo e os professores e alunos (usurios) esto acostumados a realizar as operaes de consulta (verificao se a referncia existe e est disponvel na biblioteca), retirada (de uma referncia disponvel na biblioteca) e devoluo (a referncia passa a ficar novamente disponvel na biblioteca). Todos os professores e alunos que queiram realizar as operaes mencionadas em uma das bibliotecas, devem ser catalogados como usurios da mesma. Para que o usurio possa realizar as operaes necessrio verificar se ele est em dia com a biblioteca, ou seja, no pode estar em atraso com a devoluo de nenhuma referncia. A biblioteca deve tambm atender a determinados cursos que necessitam de referncias especficas, permitindo reservar referncias para cursos de forma que as mesmas no possam ser retiradas pelos usurios durante o perodo da reserva. Uma vantagem desta unificao que foi possvel estabelecer um servio de permuta de referncias entre bibliotecas, permitindo aos usurios solicitarem referncias que no estejam disponveis em suas bibliotecas. Essa nova operao no imediata, pois requer um tempo para se requisitar a referncia em outra biblioteca. Por isso, a biblioteca do usurio deve manter um registro das referncias que cada usurio solicitou e ainda no recebeu.


A prefeitura de um municpio, para poder realizar uma obra de pavimentao de ruas, toma as seguintes providncias. Primeiramente, a Secretaria de Obras e Transportes encaminha uma solicitao de pavimentao, identificando o nome das ruas e seus respectivos trechos que devem ser pavimentados. Com base nesta solicitao, os trechos so separados por bairros. Para cada bairro existe uma classificao prvia, baseada em estatsticas realizadas no trnsito, identificando se o movimento no bairro altssimo, muito alto, alto, mdio, baixo ou muito baixo. Para cada uma destas classificaes corresponde um tipo de material a ser utilizado. Para cada trecho feito um oramento prvio, baseado no tipo de material a ser utilizado e a quantidade necessria deste material, que informado pelo Setor de Engenharia da prefeitura. Os oramentos prvios so enviados para a Secretaria de Planejamento do municpio, que emite parecer favorvel ou desfavorvel. Nos casos em que o oramento prvio recebe parecer favorvel, gerado um edital de concorrncia pblica, que publicado no Dirio Oficial do municpio. As empreiteiras interessadas encaminham propostas, contendo oramentos detalhados, que so conferidos e analisados. Os

3333

oramentos mais vantajosos para o municpio so encaminhados para a Secretaria de Planejamento, que ir decidir qual empreiteira ser contratada. Uma vez que a Secretaria de Planejamento informa qual ser a empreiteira, gerado um contrato que encaminhado para a empreiteira selecionada assinar.


A Fbrica de Balas Doce Mundo tem seu sistema de vendas baseado em pedidos feitos por seus clientes atravs de fax, telefone, carta ou atravs de representantes de vendas que circulam pelos supermercados, bares, mercearias e panificadoras da cidade e regio. Para cada pedido verificado se h quantidade suficiente do produto em estoque para atender imediatamente a solicitao. Se houver, a remessa feita ao cliente, atualizando o estoque, e enviada uma cobrana para um dos bancos conveniados, onde o cliente dever efetuar o pagamento. Quando no houver quantidade suficiente para um atendimento imediato, o pedido ser deixado como pendente. Todos os pagamentos efetuados no banco sero enviados diariamente Fbrica de Balas Doce Mundo, atravs do que ser efetuado um controle dos clientes em atraso, que recebero uma notificao da empresa para efetuarem o pagamento.

3.12. Faa o Diagrama de Contexto, a partir do DFD nvel 0 abaixo, sobre um sistema de materiais:

3434


O aluno, para matricular-se na Universidade, deve levar o formulrio de matrcula, devidamente preenchido at o guich de atendimento. Com base nestes formulrio, feita a conferncia se o mesmo est preenchido corretamente. Se estiver preenchido corretamente, verificado se no esthavendo choque de horrio, com base no quadro de horrios da Instituio. Se houver choque de horrios, o formulrio de matrcula devolvido para o aluno, rejeitando assim a matrcula. Os formulrios corretos e sem choque de horrio sero utilizados posteriormente para fazer a verificao de existncia de vagas, gerando um extrato de matrcula para o aluno e o carn para a Tesouraria. As vagas confirmadas sero utilizadas para gerar o dirio de classe que ser enviado ao professor.

3.14. Dado o Diagrama de Fluxo de Dados abaixo, identifique, se houver, e justifique os erros de sintaxe:

3.15. Faa o Diagrama de Contexto, a partir do DFD nvel 0 a seguir, sobre um sistema de imposto de renda:

3535


Uma agncia de empregos tem atuado nas mais diversas reas de recursos humanos, cadastrando oportunidades de empregos para empresas da regio e fazendo a seleo para preenchimento destas vagas. Uma empresa quando quer contratar funcionrios, informa a agncia de empregos o nmero de vagas, o cargo, os requisitos e o salrio. De posse destes dados a agncia organiza as oportunidades de emprego por cargos e faixas salariais. Duas vezes por semana, a agncia de empregos faz um ou mais anncios em jornais contendo as novas vagas e aquelas que ainda noforam preenchidas. Quando um candidato se interessa por uma ou mais vagas oferecidas atravs da agncia de emprego, ele preenche uma ficha de cadastramento e entrega um curriculum vitae, que so armazenados para avaliao posterior. Para cada vaga dado um prazo mnimo de uma semana aps o anncio ser publicado para que seja realizada a seleo. A seleo feita com base nos requisitos solicitados pela empresa contratante. Aps a seleo, o candidato aprovado encaminhado empresa contratante para que seja feita a admisso.


Uma concessionria de veculos possui uma oficina para prestao de servios de manuteno e reviso dos veculos da marca comercializada por ela. O cliente, ao chegar na recepo da oficina, atendido por um consultor tcnico, informando os dados do veculo e os defeitos percebidos. Com base nestas informaes, o consultor tcnico preenche uma solicitao de servios que iracompanhar o veculo enquanto ele estiver na oficina, uma vez que nem sempre possvel iniciar o

3636

conserto logo que esta solicitao de servios preenchida. No incio do servio, os mecnicos analisam o veculo, com base na solicitao de servios, procurando detectar os defeitos. Quando o defeito localizado, se houver necessidade de substituir alguma pea, feita uma requisio de peas, que encaminhada ao almoxarifado, que envia a pea solicitada. A pea trocada e o tempo gasto tanto nesta troca, como na anlise registrada na solicitao de servios. Com base neste tempo gasto e no preo das peas anotadas na requisio de peas anotadas na requisio de peas, feito o clculo do valor a pagar, que ser informado ao cliente, que, por sua vez, efetua o pagamento, que ser utilizado para dar baixa na solicitao de servios e enviado Tesouraria da empresa.


Uma livraria, para atender a seus clientes, recebe diariamente os pedidos de livros dos clientes. Este pedido analisado para verificar se existe o livro solicitado em estoque. Caso no exista enviada uma solicitao de compra para o fornecedor do livro no final do dia, contendo todos os pedidos feitos durante aquele dia. Uma vez que a solicitao de compra seja atendida pelo fornecedor, este enviar uma ordem de chegada, com a qual a livraria atualizar o estoque.


Uma empresa pblica possui seu quadro de funcionrios baseado em vagas definidas pelos seus departamentos. Quando ela precisa contratar funcionrios, aberto um edital que identifica todas as vagas abertas para preenchimento e seus respectivos cargos. Cada uma destas vagas solicitada por um departamento. O candidato, ao inscrever-se para o concurso, informa a qual edital e a qual vaga estar concorrendo. Uma vez apurados os resultados, informado se o candidato est aprovado ou no. Os candidatos aprovados so chamados para a admisso. Uma vez admitido, o funcionrio alocado a um departamento e registrado com o cargo correspondente vaga para a qual se inscreveu. Este funcionrio recebe um carto-ponto mensal, que servir de base para calcular a folha de pagamento e gerar o seu comprovante de pagamento. A folha de pagamento calculada mensalmente. Conforme o funcionrio for evoluindo dentro da empresa, ele pode receber promoes, que ficaro registradas no histrico do funcionrio. O cargo que ele ocupa no momento da admisso tambm registrado neste histrico.


A Metalrgica MTL S/A recebe seus clientes quando estes desejam que algum produto seja fabricado. O cliente informa qual o produto desejado e, com base nisto, o setor de vendas verifica se o produto desejado est coerente com as linhas de produtos comercializadas pela empresa, uma vez que a mesma no fabrica seus produtos em srie, mas de acordo com as necessidades do cliente. Uma vez que o produto desejado possa ser fabricado pela empresa, o setor de vendas estabelece um contrato, explicitando as especificaes do produto e as condies de pagamento, incluindo preo e

3737

prazo de entrega e de pagamento. Este contrato firmado com o cliente, gerando o compromisso de cumprimento dos prazos e especificaes. Para que o contrato firmado possa ser enviado para a produo, os engenheiros desdobram o contrato em partes para que possam ser fabricados separadamente. Cada uma destas partes recebe uma identificao e fica sendo conhecida como encomenda. O contrato enviado para o Setor de Engenharia do Produto, para que este possa analisar como ser fabricada cada parte do produto desejado. Desta forma, a Engenharia do Produto informa como fica a estrutura do produto. Com base nesta estrutura, feita uma identificao de qual parte do produto refere-se a cada encomenda. Uma vez estabelecida esta relao, cada encomenda desdobrada em partes menores, que so chamadas de roteiros de fabricao. Cada roteiro de fabricao, por sua vez, desdobrado em operaes. Depois disso, feito um planejamento de tempo para cada operao. Os roteiros de fabricao acompanham o processo de produo. Para cada operao de um roteiro de fabricao, designado um funcionrio e uma mquina para realiz-la. Aps a execuo da operao, o funcionrio registra o tempo realizado, a mquina utilizada e a qual roteiro de fabricao a operao est associada. Este registro feito em uma ficha de apontamento de mo-de-obra. Estas fichas de apontamento de mo-de-obra so conferidas com os tempos previstos de cada operao do roteiro de fabricao, com o objetivo de medir a produtividade do funcionrio. No final do dia, todas as fichas so enviadas para o Setor de Custos para acompanhamento das encomendas. A cada operao realizada, o componente do produto fabricado enviado para o Setor de Montagem, para montar o produto final solicitado pelo cliente.


Uma empresa de assistncia tcnica de eletrodomsticos atende seus clientes atravs da visita de tcnicos especializados ao local determinado pelo cliente. O cliente, quando necessita de algum atendimento, liga para a empresa, informando seu nome, endereo, o eletrodomstico que est com problema e uma br

apostilawaldoifpr.pdf

Documents