Analise de sistemas

Prévia do material em texto

CEEPRPMA/BERTOLÍNIA-PI		ANÁLISE DE SISTEMAS
Análise de Sistemas
2º Ano Técnico em Informática CEEPRPMA
Professor: José Martins
Conteúdo
1 ANÁLISE DE SISTEMAS	3
1.1 introdução	3
1.2Problemas no Desenvolvimento de Sistemas	3
1.4 Etapas desenvolvimento software	8
1.5 O Perfil do Analista de Sistemas	8
1.5.1 O Aprendizado e a Comunicação	10
2A MODELAGEM DE SISTEMAS	15
2.1 Técnicas de Levantamento requisitos de software	17
2.1 O Ciclo de Vida do Sistema	19
2.2 Metodologias de Desenvolvimento de Sistemas	22
3. FERRAMENTAS DE MODELAGEM	30
3.1 O diagrama de Fluxo de Dados(DFD)	30
3.1.1 O Conceito de Função	31
3.2 O Fluxo de Dados	32
3.3Os Depósitos de Dados	33
3.4 As Entidades Externas	34
Identifique:	37
4 DIAGRAMA DE CONTEXTO	40
5 NIVELAMENTO E BALANCEAMENTO	44
6 O DICIONÁRIO DE DADOS	48
6.1 Descrições dos Fluxos de Dados	49
6.2 Descrição dos Depósitos de Dados	51
7 A ESPECIFICAÇÃO DOS PROCESSOS	54
7.1 Português Estruturado	55
7.2 Pseudocódigo	58
7.3 Tabela de Decisão	58
7.4 Árvore de Decisão	62
8 REGRAS PARA A CONSTRUÇÃO DE DFDS	64
1 ANÁLISE DE SISTEMAS
1.1 Introdução
	O desenvolvimento de software é uma atividade de crescente importância na sociedade contemporânea. A utilização de computadores nas mais diversas áreas do conhecimento humano tem gerado uma crescente demanda por soluções computadorizadas.
	É importante observar que, associada ao acréscimo da demanda, a evolução do hardware tem sido mais acentuadas, disponibilizando aos usuários máquinas cada vez mais velozes e com maior capacidade de processamento. Neste contexto, identificou-se, já na década de 70, uma situação crítica no desenvolvimento de software, a chamada Crise do Software [Pressman], caracterizada pelos seguintes fatos:
· Demanda muito superior à capacidade de desenvolvimento;
· Qualidade insuficiente dos produtos; 
· Estimativas de custo e tempo raramente cumpridas nos projetos.
	Visando melhorar a qualidade dos produtos de software e aumentar a produtividade no processo de desenvolvimento, surgiu a área de pesquisa denominada Engenharia de Software.
	A Engenharia de Software busca organizar esforços no desenvolvimento de ferramentas, metodologias e ambientes de suporte ao desenvolvimento de software.
Dentre as principais atividades de um processo de desenvolvimento de software, destaca-se a atividade de análise e especificação de requisitos, na qual os requisitos de um sistema são levantados e modelados, para só então ser projetada e implementada uma solução (FALBO, 2002).
1.2 Problemas no Desenvolvimento de Sistemas
	O processo de informatização das atividades administrativas de uma empresa traz inúmeras implicações, que vão desde mudanças nas rotinas de trabalho até reestruturações organizacionais, com toda a problemática que daí, invariavelmente, decorre.
	Em certos casos, devido à grande pressão exercida pelos usuários, tenta-se resolver o problema da informatização através de uma visão mecanicista de realidade. Esta solução leva a tentativas de solução, quase sempre, de natureza instrumental, como acontece quando a direção da empresa é convencida por um fornecedor de “hardware” ou de “software” que lhe garante ser o produto, por ele vendido, o remédio para todos os males que afligem a empresa. Isto, sem dúvida, não costuma dar certo, pois sabemos que a simples aquisição de tecnologia de “hardware” ou de “software” não é, por si só, suficiente para resolver certos problemas que dependem fundamentalmente de um planejamento estratégico e tático, obviamente necessário a uma boa administração. Antes de escolher qualquer produto, seja hardware ou software, temos de determinar quais são os sistemas de que realmente a empresa necessita e quais são as suas características. Aliás, lembrando o filósofo Platão: “Para a nave que não tem nenhum ponto de destino qualquer vento é bom” (Embora possa haver alguma gratificação no movimento).
	Em vista disso, a informatização de uma organização empresarial deve ter como preocupação o conhecimento de todas as necessidades nos níveis estratégicos, tático e operacional, não apenas contempladas pelos sistemas atuais mas também nos sistemas futuros sejam eles automatizados ou não. Portanto, precisa-se de uma boa quantidade na especificação das necessidades, com descrições voltadas para a missão e os objetivos da organização.
	A tarefa de especificar os sistemas de informações que compõem uma empresa é uma das mais complexas e, em última análise, é um processo de solução de problemas. Para ser bem feita requer não apenas conhecimentos de computação, mas boa dose de vários conhecimentos conexos, por seu caráter interdisciplinar.
	A literatura de informática cita uma série de problemas de desenvolvimento de sistemas que são a natureza técnico-econômica, tais como: produtividade da equipe, correção da especificação, confiabilidade do sistema, manutenbilidade do código-fonte, segurança dos dados, desempenho e portabilidade do sistema. Evidentemente estes são problemas reais e importantes, que requerem uma atenção especial. A solução para estes problemas está na adoção de um tratamento sistemático que viabilize, senão a sua eliminação, pelo menos a sua minimização. As metodologias de desenvolvimento de sistema com as que fazem uso das técnicas aqui apresentadas são um grande passo para resolver estes problemas, como poderá ser desejável para os analistas de sistemas e a questão do aprendizado e da comunicação.
	Desde os primórdios da informática, a instalação dos usuários com o atendimento de suas necessidades de sistemas de informação é causa de transtornos para os profissionais da área. Vários autores internacionais documentaram este fenômeno, valendo citar, por exemplo.
	Há evidências e agrupamento teóricos de que inadequação dos sistemas é comum, que os profissionais de informática tendem, durante a fase de desenvolvimento dos sistemas, a dar maior atenção aos aspectos relativos à eficácia ou à adequação dos sistemas às necessidades dos usuários. Este tema costumava ser relegado a um plano inferior e, infelizmente, essa ainda tem sido a regra em algumas situações, hoje em dia, Muitas vezes, encontramos soluções brilhantes do ponto de vista do “desempenho” da máquina, mas que não resolvem o problema do usuário.
	A conduta a ser adotada durante o desenvolvimento de sistemas deve ser tal que conduza à construção de sistemas efetivos, isto é, sistemas que não sejam apenas eficientes, mas também eficazes; que façam exatamente o que é útil e necessário para os usuários particularmente e para a empresa de modo global. Ou seja, que não se dê ênfase apenas às preocupações com o custo, mas que, sobretudo, atente-se para aderência do sistema às necessidades do usuário, parâmetro que serve para exprimir seu valor ou utilidade. Podemos dizer que entre as razões pelas quais é baixo o grau de satisfação dos usuários com os seus sistemas automatizados sobressai à inadequação da abordagem utilizada para a fase de desenvolvimento para os usuários.
	Entre as principais deficiências encontradas na maioria das abordagens utilizadas no desenvolvimento de sistemas está o fato de elas enforcarem apenas aspectos técnico-econômicos em problemas que, normalmente, têm forte componente psicossocial. Este é, com frequência e indevidamente, negligenciado.
 Um claro exemplo das dificuldades enfrentadas pela tentativa de utilização de enfoque apenas técnico-econômico está na proposta do uso de banco de dados como fator de integração de empresa. Tal proposta, embora muito atraente do ponto de vista técnico-econômico é de difícil implementação pelo menos quando se quer o preconizado na teoria. Note que estamos nos referindo a banco de dados como ponto-chave da integração dos sistemas, desde o seu nível de especificação conceitual, e não apenas como solução de problemas de armazenamento de dados. Isto acontece justamente porque um dos famosos “donos do dado”, o que, sem dúvida, não pode ser resolvido sem uma análise do aspecto social da organização. Dados gerências ou operacionais, quando representando informações importantes,são fontes de disputa de poder. Em razão desta constatação, apenas um especialista em computadores.
	A partir do advento dos microcomputadores, a tecnologia de hardwaree de software evoluiu rapidamente, e hoje são oferecidas ao próprio usuário enormes facilidades para o uso desses recursos. Em auxílio aos analistas, o avanço tecnológico trouxe, entre outras facilidades, o surgimento dos softwares do tipo CASE (Computer Aided Software Engineering) para apoio ao desenvolvimento de sistemas. Estes softwares podem proporcionar um significativo aumento de produtividade. Por tudo isto, fica cada vez mais evidente a necessidade de o analista ter um perfil mais voltado para especificação dos requisitos do sistema e dos negócios de empresa do que apenas para o conhecimento da programação e operação de máquinas.
1.3 Sistemas de Informação nas Organizações.
	Sistemas de informação atualmente servem em todas as áreas e níveis das organizações, sendo considerados como ferramenta essencial para o sucesso de suas atividades. Isso nos permite classificá-los de acordo com a responsabilidade assumida por seus usuários dentro da organização em quatro tipos principais (LAUDON, 2001).
· Sistemas de nível operacional, que tratam da execução, acompanhamento e registro da operação diária da empresa, sendo geralmente sistemas fortemente transacionais. Exemplos são sistemas de vendas, folha de pagamento, etc.
· Sistemas de nível de conhecimento, que suportam as pessoas que trabalham com dados e conhecimento dentro da organização. Exemplos simples de sistemas desse tipo são os processadores de texto e as planilhas eletrônicas.
· Sistemas de nível gerencial, que utilizam dados da operação e outros dados inseridos nesses sistemas para permitir a obtenção de informações que permitam a gerência da empresa, suportando a tomada de decisões, o controle e o monitoramento.
· Sistemas de nível estratégico, que são sistemas destinados a decisões de mais alto nível (efeito estratégico) e utilizam dados de todos os sistemas anteriores, normalmente de forma agregada e processada, sendo utilizados pela alta gerência (LAUDON, 2001).
Figura 1: Níveis dos sistemas de informação dentro de uma organização (LAUDON, 2001, p.9).
	Cada uma dessas perspectivas é suportada por uma maneira de expressar a realidade registrada por meio de um modelo que a descreve, segundo uma forma de representação (POMPILHO, 2002).
	Assim, considerando que uma organização empresarial pode ser entendida como sendo um sistema, ele pode ser bem compreendida se apresentarmos três modelos que, conceitualmente, a representam, a partir de três perspectivas que se complementam:
· Um modelo funcional, que apresenta uma visão estruturada das funções ou dos processos que compõem a organização;
· Um modelo de dados, que apresenta uma visão dos dados que serão armazenados para serem usados pela organização;
· Um modelo de controle, representando as transformações de controle e uma visão do comportamento da organização em relação aos seus diferentes estados válidos, cada um dos quais sendo caracterizado por uma determinada resposta fornecida quando a organização estiver sujeita a certo conjunto de estímulos.
1.4 Etapas desenvolvimento software
	Um completo entendimento dos requisitos do software é essencial para o sucesso de um esforço de desenvolvimento de software. A atividade de análise e especificação de requisitos é um processo de descoberta, refinamento, modelagem e especificação. O escopo do software definido no planejamento do projeto é refinado em detalhe, as funções e o desempenho do software são especificados, as interfaces com outros sistemas são indicadas e restrições que o software deve atender são estabelecidas. Modelos dos dados requeridos, do controle e do comportamento operacional são construídos. Finalmente, critérios para a avaliação da qualidade em atividades subsequentes são estabelecidos (FALBO, 2002).
	Desenvolver software é a atividade, de longo prazo, de criar um ou mais programas de computador, um sistema, de forma a atender necessidades específicas de um cliente ou grupo de clientes.
	No desenvolvimento de software realizamos as atividades de descoberta das necessidades e de criação do produto de software propriamente dito. Podemos dividir as atividades do processo de desenvolvimento em alguns grandes grupos:
· Atividades de Análise, cuja finalidade é descobrir “o que” deve ser feito;
· Atividades de Projeto, cuja finalidade é descobrir “como” o software deve ser feito;
· Atividades de Implementação, cuja finalidade é produzir o produto de software de acordo com as especificações produzidas nas fases anteriores;
· Atividades de Controle de Qualidade, onde se incluem todas as atividades com objetivo de garantir a qualidade do produto, como testes e verificações (XEXÉO,2007).
1.5 O Perfil do Analista de Sistemas
	Para ter boa probabilidade de sucesso o analista de sistemas deve possuir uma formação que vai além das disciplinas voltadas para o conhecimento de computadores. No qual o seguinte conjunto de habilidade seria mais adequado para o bom desempenho na atividade de análise de sistemas de informação administrativos:
· Comunicação: entendida como capacidade para ouvir, redigir e expor idéias com clareza e precisão, aprender e expressar o conteúdo do aprendizado com facilidade;
· Capacidade de análise: entendida como aptidão para realizar operações mentais com abstrações sobre o recorte da realidade em estudo. Possuir uma visão sistemática e critica do contexto em análise, além de habilidade para distinguir e conceituar categorias de significados de noções concretas e abstratas associadas aos negócios da empresa;
· Conhecimento da área usuária: entendido, principalmente, como aquele tipo de conhecimento que não pode ser obtido através de treinamento mas adquirido por meio de experiência pessoal ao longo da vivência com operações da empresa;
· Capacidade de negociação: entendida como habilidade em obter resultado desejado, ainda que em condições adversas, e capacidade de administrar conflitos de interesses interpessoais que surjam durante o trabalho em grupo;
· Administração de projetos: entendido como noções sobre alocação de tempo e recursos humanos, financeiros e materiais necessários a projetos, nos quais participam pessoas de formações diferentes, num empreendimento de característica interdisciplinar, procurando sempre a efetividade, garantindo não só a eficiência como também a eficácia do processo de obtenção dos resultados a serem alcançados;
· Conhecimento Técnico: entendido como capacidade de especificar sistemas de informação, principalmente nas suas fases de nível de abstração mais alto, utilizando ferramentas de modelagem, especialmente as adotadas pela técnica de análise essencial. Pode ser útil, ainda, o conhecimento das estruturas lógicas do Sistema Gerenciador de Banco de Dados utilizados pela empresa;
Os requisitos acima colocados constituem o perfil considerado por nós como ideal. Reconhecemos, todavia, a dificuldade de se terem à disposição profissionais com essa capacitação. Para iniciar-se na atividade de análise de sistemas, não é condição indispensável à proficiência em todas as habilidades mencionadas. 
	As funções de analista, projetista e programador são, às vezes, confundidas. Para esclarecer este ponto, podemos dizer que, a rigor, o papel do analista de sistemas é especificar quais são os requisitos do sistema do ponto de vista eficácia, ou seja, garantir que o sistema alcance os objetivos globais da empresa. Trata-se de certificar-se de que o sistema fará o que precisa ser feito, fará o que é certo ser feito, independentemente da instrumentação que será usada para chegar a esse objetivo. Por sua vez, o projetista tem um papel voltado para eficiência, isto é, voltando para a obtenção do melhor desempenho individual dos componentes do sistema. Por fim, o papel do programador é construir (implementar) o sistema de acordo com as especificações feitas pelo projetista.
1.5.1 O Aprendizado e a Comunicação
	Para bem realizara especificação de um sistema de informação, o primeiro passo a reconhecer que atividade de desenvolvimento de sistemas é, em essência, um processo de solução de problemas. E, como tal, esse processo compõe-se em de uma fase de aprendizado (entendimento dos requisitos dos sistemas) e outra de comunicação (apresentação, da solução encontrada para aprovação dos usuários). Ambas as fases devem ser executadas, de modo interativo, por refinamentos sucessivos, para se obter, por fim, o melhor resultado.
	Normalmente, quando um analista inicia o desenvolvimento de um sistema, ele sabe pouco ou quase nada sobre o sistema a ser desenvolvido. Portanto, o desenvolvimento começa com uma fase de aprendizado. A obtenção dos requisitos necessários ao sistema torna-se bastante dificultada, pois o usuário expõe o seu problema em linguagem natural, podendo ainda não ser capaz de expressar adequadamente as suas necessidades. Isto pode resultar em problemas de consistência ou má interpretação, o que, sem dúvida, irá acarretar erros cuja a consequência poderá ser muito cara. Por tudo isto, trata-se de uma tarefa bastante delicada.
	A fase do aprendizado é de grande complexidade, e várias são as teorias sobre os mecanismos pelos quais ela se processa. Entre essas teorias, podemos exemplificar:
	Na primeira etapa, partimos da observação da realidade, tentando obter uma visão global do assunto em estudo. Isto, na verdade, é buscado através de um processo não-estruturado e tem as características de uma coleta de conhecimentos, que serão reunidos no tema abordado. É a rigor um processo informal, através do qual tentamos juntar todos os fatos relevantes a respeito do problema em questão e descobrir os relacionamentos entre estes fatos. Geralmente, o analista, nesta fase, de posse de todo o conhecimento coletado, tem dificuldade de separar o que realmente é relevante para o sistema.
	Na segunda etapa(análise), já partimos da visão global, obtida na fase anterior. Nesta hora, o processo de aprendizagem passa pela construção de uma espécie de maquete, o que consiste em identificar as variáveis ou pontos-chave do problema para construção de modelo simplificado com sua estrutura, com seus elementos e relações, possibilitando, destaque, que ai se faça, tendo como suporte um modelo do problema. Ao final desta fase, o analista já tem uma idéia do tudo e de suas partes.
	A última etapa será, então, aquela em que se irão propor hipótese de solução a serem adotadas. É a etapa chamada síntese; ao final, tem - se idéia de todo o sistema, quais as suas partes e qual a solução proposta para o problema. Cabe assinalar que, diferentemente de algumas áreas de ciência exatas, não estamos tratando de um problema que tenha uma única solução correta, mas buscando uma que seja aceitável entre as soluções possíveis.
	Como se pode observar, é bastante complexo o processo de aprendizado. Fica fácil entender porque se costuma errar tanto na hora de se prever um prazo para o desenvolvimento de um sistema, especialmente o prazo para as primeiras fases de especificação. É muito difícil prever o tempo que alguém vai levar para compreender, com exatidão, todos os requisitos de um sistema. Além disso, o tempo para se aprender algum assunto varia muito de pessoa para pessoa. A capacidade de aprender com eficiência é também, em nossa opinião, uma habilidade considerada importante para os profissionais de desenvolvimento de sistemas. A compreensão do domínio do problema a ser resolvido é realmente um ponto crucial da análise de sistemas se compreendermos bem um problema já tem um grande avanço para a solução.
	Uma vez terminada a fase de aprendizado, entramos na fase de comunicação com o usuário. Esta fase também tem fatores que dificultam. Os principais gargalos num processo de comunicação ocorreram por conta de problemas das seguintes naturezas:
· Problemas psicológicos: relacionados com percepção, atenção, motivação, atitudes, memória, hábitos de pensamento;
· Problemas semiológicos: relacionados com o emprego de signos e códigos para comunicar: palavras, gestos, tom de voz, coisas escritas etc.
· Problemas semânticos: relacionados com os significados das palavras, dos objetos e das pessoas, assim como com sua interpretação;
· Problemas sintáticos: relacionados com a estrutura ou organização dos conteúdos e dos significados;
· Problemas cibernéticos: relacionados com retro informação e diálogo, com a quantidade de idéias transmitidas por diversos canais e com capacidade destes para levarem sinais;
	A literatura específica de desenvolvimento de sistemas até que tem reconhecido o problema da comunicação. Nesta literatura, têm sido apresentadas várias técnicas, todas visando minimizar as dificuldades da comunicação entre os desenvolvedores de sistemas e os usuários. Sabemos que o sucesso de um sistema dependerá fundamentalmente de sua aceitação por parte do usuário. Para tanto, devemos apresentar a solução proposta a todos os que, de alguma forma, puderem contribuir para a descoberta da solução mais adequada ao ambiente no qual o sistema será implantado. Isto implica necessariamente de uma linguagem (forma de expressão) comum a ser usada por profissionais de formações diferentes, num empreendimento de característica interdisciplinar. 
ATIVIDADE
1) Defina análise de sistemas. 
2) A análise de sistemas é um processo de transmissão de conhecimento e, assim sendo, envolvem três etapas, quais?
3) Qual a importância da Análise de Sistema para o desenvolvimento de Software?
4) De acordo com Pressman que fatos caracterizaram a chamada Crise do Software?
5) De acordo com FALBO quais as principais atividades de um processo de desenvolvimento de software?
6) Quais os principais problemas no desenvolvimento de sistemas?
 
7) Como podemos classificar os Sistemas de Informação nas Organizações? 
8) Quais os Níveis dos sistemas de informação dentro de uma organização? Explique cada um deles.
9) Considerando que uma organização empresarial pode ser entendida como sendo um sistema, ele pode ser bem compreendido se apresentarmos três modelos que, conceitualmente, a representam, a partir de três perspectivas que se complementam, são eles:
10) Quais as etapas de desenvolvimento de software? Especifique cada um deles.
11) Que habilidades seria mais adequado para o bom desempenho na atividade de análise de sistemas de informação por um analista?
12) Diferencie as funções dos analistas, projetista e programador nas atividades de analise de sistemas.
13) “Para bem realizar a especificação de um sistema de informação, o primeiro passo é reconhecer que atividade de desenvolvimento de sistemas é, em essência, um processo de solução de problemas”. Sobre a afirmativa é incorreto afirmar que:
a) Esse processo compõem-se em de uma fase de aprendizado (entendimento dos requisitos do sistemas) e outra de comunicação (apresentação, da solução encontrada para aprovação dos usuários). 
b) Normalmente, quando um analista inicia o desenvolvimento de um sistema, ele já sabe tudo sobre o sistema a ser desenvolvido. Portanto, o desenvolvimento começa com uma fase de solução encontrada para aprovação dos usuários.
c) A obtenção dos requisitos necessários ao sistema torna-se bastante dificultada, pois o usuário expõem o seu problema em linguagem natural, podendo ainda não ser capaz de expressar adequadamente as suas necessidades. Isto pode resultar em problemas de consistência ou má interpretação, o que, sem duvida, irá acarretar erros cuja a consequência poderá ser muito cara. 
d) Desenvolver software é a atividade, de longo prazo, de criar um ou mais programas de computador, um sistema, de forma a atender necessidades específicas de um cliente ou grupo de clientes.
2 A MODELAGEM DE SISTEMAS
	
	Desde que foi percebido pelos profissionais de informática que grande parte das deficiências nas especificações de sistemas era devida à problemática de comunicação, um esforço considerável tem sido realizado no sentido de se superar este problema. Para tanto, construíram-sevárias propostas metodológicas, que enfatizam a necessidade de uma linguagem a ser empregada pelos analistas de sistemas, linguagem essa que pudesse ser compreendida também pelos usuários.
	Dentro desta linha, desenvolveram-se linguagens que passaram a incluir os recursos necessários para definir as necessidades do usuário, independentemente de qualquer restrição relativa à implementação. Ou seja, linguagens de especificação que, se tornem mais inteligíveis ao usuário não-técnico e por outro lado, permaneçam suficientemente precisas, para permitir que se produza uma especificação que seja base para um subsequente projeto operacional dos sistemas de informação necessários.
	Este tipo de linguagem deve possuir recursos que permitam produzir uma especificação que possa ser apresentada ao usuário e com ele discutida. Um erro muito comum no passado, entre os profissionais de informática, era a crença de que todas as necessidades de informações seriam conhecidas “apriori” pelos usuários. A prática mostrou que isto não era verdade, o que faz com que está restrição deva ser considerado com devido cuidado na solução do problema da linguagem.
	O fato do usuário não saber “a priori” todos os requisitos do sistema a ser construído não é uma característica exclusiva de problemas da área de desenvolvimento de sistemas. Na verdade, isto é comum em qualquer ramo de atividades onde haja complexidade que exija especificação, na qual seja necessário mostrar claramente o que se quer construir, para que todos aqueles afetados pelo produto final do trabalho possam certificar-se de que se está no caminho certo.
	Duas abordagens complementares são bastante utilizadas sempre que nos deparamos com problemas muito complexos. A primeira é tentar decompor o problema em subproblemas que possuam menor complexidade que o problema original, não se esquecendo de utilizar um método de decomposição que nos garanta a possibilidade de, a partir dos subprogramas, reconstituir o todo.
É evidente que se devem fazer parte integrante do método o reconhecimento e a descrição dos elementos de ligação entre os subprogramas constituintes do todo. Assim, no caso do projeto de uma casa, poderíamos dizer que ela se compõe de uma sala, três quartos, dois banheiros, etc. 
A outra abordagem consiste em decompor o problema não por partes, como um mosaico, mais por pontos de vista diferentes. Nesta abordagem diríamos que a casa compõe-se de planta de instalação elétrica, uma planta de instalação hidráulica etc.., onde todas as plantas referem-se à casa e não apenas uma das partes. Novamente, a integração entre os componentes do problema original se faz necessária, visto que as plantas componentes da casa não podem ser tratadas isoladamente. Por exemplo, o que aconteceria se, por falta de integração, a planta de instalação elétrica determinasse a passagem de um cabo elétrica justamente pelo mesmo local onde a planta de instalação hidráulica especificasse a passagem de um cano d’água?
	O exemplo apresentando apenas tem por objetivo ilustrar algumas das dificuldades enfrentadas na solução de problemas complexos, e chamamos a atenção do leitor para a utilidade de uma planta para descrever o projeto mencionado, a qual possibilita a resolução de algumas questões de natureza técnica, antes do início da construção, o que se traduz em economia no custo total. Os requisitos do futuro usuário da casa, quanto às suas necessidades, poderão ser discutidos fazendo-se uso da planta, o que ajuda a garantir a adequação do projeto às necessidades do usuário. Desta forma, a planta funciona como um modelo reduzido e mais barato da casa e serve ainda como mecanismo (leia-se, linguagem) de comunicação entre técnicos e entre usuários e técnicos, pois, em problemas complexos, a solução ideal só será alcançada se os técnicos tiverem forte interação com os usuários e, para tanto, um modelo do empreendimento deverá ser produzido.
	Do que foi expresso fica absolutamente claro que o exemplo da casa, antes de se construir um sistema de informações, deve-se elaborar um modelo que seja capaz de expressar com a máxima fidelidade possível o conhecimento que se tem do ambiente onde o sistema será implantado, de modo a satisfazer a todos os requisitos necessários. Se, por um lado, o custo de um sistema é função do desempenho de seus componentes, por outro, o valor deste mesmo sistema é função da utilidade que ele tenha para seus usuários. A boa técnica de análise dos sistemas de uma empresa preconiza uma boa interação, vale dizer, comunicação - entre os usuários e os técnicos de informática.
	O principal produto da análise são modelos que darão origem aos sistemas. Entre as utilidades de um modelo, se destaca as seguintes:
· Estabelecer uma visão comum. (entre usuários e analista) do ambiente antes da automação;
· Servir como suporte para negociação e especificação de requisitos e possibilidades futuras para o sistema;
· Representar, avaliar e refinar conceitos do projeto;
· Escalonar a informatização em frases, com produtos bem definidos e dependência mínima entre as fases;
· Tratar a complexidade do problema por níveis de abstração, começando pela visão mais abstrata e descendo a visões progressivamente mais detalhadas;
· Promover indicações quantitativas do escopo e da complexidade do problema;
· Prover facilidades para geração de testes de aceitação;
	Além disso, sabe-se que, na especificação dos sistemas de informação, devem ser consideradas diversas perspectivas do problema como nas diversas plantas do exemplo da construção da casa. As modernas abordagens enfatizam a perspectiva dos dados, não ignorando, entretanto, a importância da perspectiva das funções bem como a dos controles do sistema.
	Cada uma dessas perspectivas é suportada por uma maneira de expressar a realidade registrada por meio de um modelo que a descreve, segundo uma forma de representação.
2.1 Técnicas de Levantamento requisitos de software
	O início para toda a atividade de desenvolvimento de software é o levantamento de requisitos, sendo esta atividade repetida em todas as demais etapas da engenharia de requisitos.
	Análise e levantamento de requisitos são de extrema importância serve para um bom Documento de Requisitos de Software é possível visualizar e interferir em um sistema sem causar problemas à aplicação existente. Além disso, o esforço gasto na localização de qualquer tipo de modificação ou implementação se torna aceitável (SOMMERVILLE, 2003).
Figura 2.1:disponível em http://scott.yang.id.au/2003/08/software-development-life-cycle/
	Sommerville (2003) propõe um processo genérico de levantamento e análise que contém as seguintes atividades:
· Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da aplicação;
· Coleta de requisitos: É o processo de interagir com os usuários do sistema para descobrir seus requisitos;
· Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes; 
· Resolução de conflitos: Quando múltiplos usuários estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos;
· Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os usuários para a definição dos requisitos mais importantes;
· Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os clientes desejam do sistema.
	O levantamento e análise de requisitos é um processo iterativo, com uma contínua validação de uma atividade para outra, conforme exemplificado pela Figura 2.2:
Figura 2.2: Processo de levantamento e análise de requisitos (SOMMERVILLE, 2003)
2.1 O Ciclo de Vida do Sistema
	Um sistema pode ser entendido como um mecanismo composto por um conjunto de partes inter-relacionadas, onde cada parte está sempre relacionada a, pelo menos, uma das outras.
	Como toda linha de produção, o desenvolvimento de sistemaspode envolver diversas fases. Ao encadeamento das fases para a construção do sistema denominamos ciclo de vida de desenvolvimento de sistemas - Há na literatura da área diversos enfoques propostos para o ciclo de vida de um sistema. Entre estes, o enfoque em cascata e o da prototipação. Adotaremos para nossa explicação o primeiro destes. Simplificadamente toma-se como base um ciclo de vida de desenvolvimento que terá as seguintes frases, na ordem apresentada a seguir:
 ANÁLISE		
 (
PROJETO
)
				
					IMPLEMENTAÇÃO
														
· Análise de sistemas ea fase do desenvolvimento em que se determinarão quais os requisitos dos sistemas, “o que”o sistema deve fazer, em termos essenciais. A fase de análise tem por objetivo interpretar e definir uma estrutura para um problema ainda não estruturado. Diz respeito à eficácia do sistema, ainda sem preocupações de “performance”.
· Por Projeto de Sistemas entenderemos a fase do desenvolvimento em que se determinará “como” o sistema funcionará para atender aos requisitos especificados na fase de análise. Diz respeito à eficiência do sistema, já com preocupações de “performance”. O objetivo desta é fase á modelar o sistema de modo a implementar a solução idealizada na fase de análise, mas de acordo com os recursos tecnológicos existentes na empresa.
· Por implementação de Sistemas entenderemos a fase do desenvolvimento em que será efetuada a construção do sistema de acordo com o modelo de funcionamento especificado na fase de projeto. Faz uso dos recursos tecnológicos existentes na empresa para atividades como a programação de computadores.
O ciclo de vida ilustrado acima é um ciclo compulsório. Todo o ciclo de desenvolvimento de sistemas terá pelo menos estas fases. Há quem inclua no ciclo de desenvolvimento uma fase de estudo, anterior à fase de análise, e duas outras fases após a implementação: são elas a simulação e a implantação do sistema. Neste caso, o ciclo de desenvolvimento ficaria assim:
 (
PROJETO
) (
ANÁLISE
) (
IMPLANTAÇÃO
) (
SIMULAÇÃO
) (
IMPLEMENTAÇÃO
) (
ESTUDO 
)																																																																									
	Uma vez implantando o sistema, duas outras fases surgem: operação e manutenção. Ao ciclo de atividades que inclui, além das fases de desenvolvimento, a operação e a manutenção de um sistema que podemos denominar ciclo de vida do sistema, e faremos a seguinte figura:
 (
ESTUDO 
ANÁLISE
PROJETO
IMPLEMENTAÇÃO
SIMULAÇÃO
IMPLANTAÇÃO
 OPERAÇÃO
MANUTENÇÃO
)																																																																																																																																																				
												
	Podemos então dizer que um sistema, uma vez implantado, entra em operações e, até que seja desativado, poderá sofrer manutenções, sejam elas corretivas por acréscimos de novos elementos. Vale ressaltar que o desenvolvimento de sistemas, na prática, não ocorre de maneira tão linear no tempo, como possa parecer pela figura do ciclo da vida. Na prática, é possível acontecer uma certa superposição de fases, principalmente entre as consecutivas, ainda que tal superposição deva ser reduzida. Por exemplo: pode ser que já se esteja na fase de projeto e seja necessário, por alguma contingência, rever uma parte da fase de análise.
2.2 Metodologias de Desenvolvimento de Sistemas
Para haver sucesso no desenvolvimento de sistemas, torna-se necessária a utilização de uma metodologia de trabalho.
	Uma metodologia pode ser entendida como uma dissertação sobre a maneira de se utilizar um conjunto coerente e coordenado de métodos para atingir um objetivo, de modo que se evite, tanto quanto possível, a subjetividade na execução do trabalho.
	Um método pode ser entendido como um procedimento a ser adotado para se atingir um objetivo. Para tanto, o método se vale de um conjunto de técnicas.
	Uma técnica pode ser entendida como sendo um modo apropriado de se investigar sistematicamente um determinado universo de interesse ou domínio de um problema. Para se expressar, uma técnica faz uso de uma notação.
	Uma notação é um conjunto de caracteres, símbolos e sinais formando um sistema é a melhor maneira de se resolverem os problemas da atividade de desenvolvimento. Deve ser definido o ciclo de vida do sistema adotado, ou seja, quais as fases de trabalho a serem executadas. Uma boa metodologia deve também apresentar definição clara de “quem” faz “o quê”, “quando”, “como”, e até mesmo “onde”, para todos os que estejam envolvidos diretamente ou não com o desenvolvimento de sistemas. Deve definir também qual o papel dos técnicos de informática, o dos usuários e o da administração da empresa no processo de desenvolvimento. Além disso, deve instituir um conjunto de padrões preestabelecidos, de modo a se evitar a subjetividade na abordagem, a fim de garantir a facilidade de integração de sistemas de desenvolvidos por grupos de pessoas diferentes em épocas distintas. As técnicas adotadas é que devem ser estáveis, e não os técnicos. Deve, assim, evitar um problema muito comum. Em algumas instalações: onde técnicos se comportam como verdadeiros “donos de determinados sistemas”, pois só eles os conhecem bem e só eles são capazes de alterá-los sem riscos, o que sem dúvida é indesejável para a administração da empresa. Tudo isto permite uma maior mobilidade na alocação dos recursos-humanos, materiais, financeiros e tempo- envolvidos na atividade e dá condições à direção do projeto de melhor controlar o trabalho em curso.
	Em face do que já foi dito, uma metodologia deve definir quais as fases de trabalho previstas no desenvolvimento de sistemas. Para cada fase, quais as técnicas adotadas. São exemplos de técnicas: 
· Análise Estruturada;
· Análise Essencial e Projeto Estruturado.
 A metodologia deve ainda, para cada técnica adotada, definir quais as ferramentas utilizadas. São exemplos de ferramentas:
· Diagrama de Fluxo de Dados;
· Diagrama de Entidade-Relacionamento;
· Diagrama de Transição de Estados. 
Cada ferramenta irá produzir um tipo de modelo. São exemplos de modelos: Modelo Funcional
· Modelo Conceitual de Dados;
· Modelo de Controle. 
A metodologia deve estabelecer ainda quais os pontos de controle e padrões de qualidade, além da responsabilidade do pessoal envolvido nos controles e métricas.
	 Tais técnicas fazem uso de ferramentas que dão origem a modelos que representam as principais perspectivas de um sistema. Entre estas, principalmente nos ambientes de sistemas de informação administrativos, as ferramentas de modelagem como as que são usadas em técnicas do tipo de Análise Estruturada e Projeto Estruturado tornaram-se bastante conhecidas.
	O quadro a seguir, apresentado em (IBPI, 1990), mostra as principais ferramentas de modelagem utilizadas na fase de análise de sistemas por três técnicas:
Análise de Sistemas
	TÉCNICAS
	ABORDAGENS
	FERRAMENTAS
	
ANÁLISE
TRADICIONAL
	
*FUNCIONAL
	
*TEXTOS
*FLUXOGRAMAS
	
ANÁLISE
ESTRUTURADA
	
*FUNCIONAL
 *DADOS
	
*DIAGRAMA DE FLUXO DE DADOS 
*DIAGRAMA DE ESTRUTURA DE DADOS
*MINIESPECIFICAÇÕES
*NORMALIZAÇÃO 
*DICIONÁRIO DE DADOS 
	
ANÁLISE 
ESSENCIAL
	
*FUNCIONAL
 *DADOS
 *CONTROLE
	
*TABELA DE EVENTOS 
*DIAGRAMA DE FLUXO DE DADOS 
*DIAGRAMA DE ENTIDADE-RELACIONAMENTO
*DIAGRAMA DE TRANSIÇÃO DE ESTADOS
*DIAGRAMA DE ESTRUTURA DE DADOS
*NORMALIZAÇÃO 
*MINIESPECIFICAÇÕES
*DICIONÁRIO DE DADOS
	
	O quadro anterior mostra também uma espécie de evolução histórica das técnicas de análise. O que estamos denominando por Análise Tradicional é a técnica que costumava ser usada para a fase de análise, antes do surgimento da Análise Estruturada. Basicamente, produzia um documento que, além de texto, usava, de vez em quando, uma ferramenta bastante popular denominada fluxograma. A abordagem usada era quase que exclusivamente voltada para a perspectiva das funções do sistema.
	Com o advento da Análise Estruturada, como se pode notar, passou-se a fazer um uso maior das ferramentas de modelagem, e a abordagem passou a contemplar tambéma perspectiva dos dados, além da perspectiva das funções.
	Finalmente, a Análise Essencial faz amplo uso das ferramentas de modelagem e opta por uma abordagem que contempla também a perspectiva dos controles, além da perspectiva das funções e dos dados. Assim, à medida que foram evoluindo as técnicas de análise, maior quantidade de ferramentas de modelagem passou a ser utilizada.
	Embora as ferramentas de modelagem sejam extremamente importantes, por razões diversas, na prática, algumas empresas ainda relutam na sua adoção. A titulo de exemplo vale mencionar que uma das queixas muito comuns entre os que relutam em usar ferramentas de modelagem refere-se ao fator tempo. É que, em suas avaliações, acreditam que, com a adoção destas técnicas, o desenvolvimento dos sistemas estende-se muito longamente. Segundo esses queixosos, fazendo-se uso de métodos mais tradicionais, chegar-se ao mesmo objetivo em tempo menor. As vantagens do uso de ferramentas de modelagem são:
	1)Identificar se o prazo para o desenvolvimento foi realmente mal estimado, sendo que, neste caso, mesmo com métodos tradicionais, não se teria acertado na previsão do tempo;
	2) Os profissionais que atuam no desenvolvimento do sistema ainda não dominavam a utilização das ferramentas adotadas pela técnica. Neste caso, a suposta lentidão se deve à falta de proficiência dos técnicos no uso das ferramentas;
	3) O diagnóstico que aponta perda de tempo é distorção de parâmetro. Isto porque, com a utilização de ferramentas que permitem um mecanismo rigoroso de verificação, muitas situações específicas de níveis mais altos-como: as fases conceitual e lógica do sistema - foram corretamente analisadas. Ora, não se pode comparar o tempo que tal análise demanda com aquele que se consumiria nas análises realizadas pelos métodos tradicionais, porquanto ai não teriam contemplado uma série de situações que as ferramentas de modelagem apontam. Análises mais pobres podem até economizar tempo, mas não cobrem a riqueza de situações que se devem identificar em análises extremamente mais abrangentes e aderentes ao mundo real.
	A chave do problema está, principalmente, no item (3). Via de regra, a utilização de métodos tradicionais deixa escapar de sua análise situações que, pouco tempo após a implantação, fazem com que o sistema comece a sofrer manutenção. Esta escolha pode ser enquadrada na categoria de soluções de curto prazo que acarretam problemas de longo prazo. Uma conclusão importante, de tudo quanto temos observado, diz que um sistema é menos sujeito a necessidade de manutenção quando mais altos, se fez uso de métodos mais formais (menos empíricos), permitindo identificar, antecipadamente, problemas que só seriam percebidos nas fases finais do desenvolvimento ou após a implantação do sistema.
	Outros problemas, também citados na utilização de ferramentas de modelagem, são o volume de documentação produzida e a dificuldade de mantê-la atualizada.
	Quanto ao primeiro problema, podemos afirmar que, para o mesmo volume de documentação, a utilização de uma ferramenta de modelagem registra uma quantidade de conhecimento (informação) maior do que a registrada por métodos tradicionais. Isto se deve, entre outros fatores, ao fato de as técnicas de modelagem fazerem uso de linguagens gráficas (bidimensionais), enquanto que as técnicas tradicionais usam a linguagem textual (que é linear). Além disso, é característica da própria ferramenta de modelagem buscar a não redundância de informações, o que, normalmente, não ocorre nos métodos tradicionais.
	Quanto à dificuldade de se manter a documentação atualizada, cabe dizer que, com qualquer técnica que se use, isto sempre foi difícil. Todavia, com o surgimento dos “softwares” para apoio ao desenvolvimento de sistemas (do tipo CASE), esse problema foi bastante minorado.
	No que diz respeito ao desenvolvimento de sistemas, vimos que a proposta de se estabelecerem modelos para cada um dos aspectos ou perspectivas do sistema pode ser de extrema utilidade. A dificuldade neste campo reside em se decidir quais os aspectos do sistema a serem apresentados em uma especificação. Dissemos que a maioria dos sistemas pode ter sua especificação bem compreendida se apresentarmos três modelos que conceitualmente representam o sistema a partir de três perspectivas que se completam: modelo funcional, modelo de dados, e modelo controle. Os sistemas podem, ainda ser classificados de acordo com a importância relativa de cada um dos três modelos para sua especificação. Desta forma, poderíamos classificar os sistemas em centrados nas funções, centrados nos dados e centrados nos controles. É verdade que haveria uma série de sistemas híbridos, os quais não seriam tão claramente definidos assim. Para exemplificar, chamaremos de sistema centrado nos dados aqueles cuja precauções(na especificação e implementação) deve ser maior em relação aos dados e seus inter-relacionamento do que em relação às operações. As aplicações de robótica são um exemplo de sistemas mis centrado nos controles e processos, enquanto que as aplicações de consulta generalizada são o extremo de sistemas centrados nos dados. O principal objeto de nosso estudo serão os sistemas de informação administrativos cujas principais perspectivas são a das funções e dos dados, especialmente esta última.
	A técnica da Analise Essencial tem como uma de suas fundamentais usar-se os eventos como base para o particionamento dos sistemas. Assim sendo, em nosso trabalho, mostraremos como efetuar a decomposição tanto das funções como dos dados do sistema a partir dos eventos, garantindo, dessa forma, que o modelo de dados e o de funções possam ser construídos simultaneamente, estando assim integrados, por construção.
	Podemos afirmar, sem receio de errar, que ao adotado a técnica da Análise Essencial, como apresentada neste livro, o leitor poderá produzir sistemas muito mais efetivos, e em tempo hábil do que se usar qualquer outra técnica tradicional. Quando se tem o método adequado para resolver um problema, facilmente se encontra a solução.
	A técnica da Análise Estruturada Moderna. Para compreender os conceitos da Análise Essencial, é necessário antes conhecer como se elabora a Modelagem Funcional e a Modelagem de Dados.
ATIVIDADE
1)Quais os principais objetivos dos modelos no desenvolvimento de sistemas?
2) Quais as fases do ciclo de vida de desenvolvimento de sistemas depois de implantado?
3) Analise as seguintes sentenças sobre modelagem de sistemas . Quantas sentenças estão incorretas
a )0		b)1		c)2		d )3
I. Um modelo enfatiza um conjunto de características da realidade, que corresponde à dimensão do modelo. Além da dimensão que um modelo enfatiza, modelos possuem níveis de abstração.
II.O nível de abstração de um modelo diz respeito ao grau de detalhamento com que as características do sistema são representadas.
III. Em cada nível há uma ênfase seletiva nos detalhes representados.
IV.No caso dos sistemas de informação, geralmente, são considerados três níveis: conceitual, lógico, físico
4)Pesquise sobre o conceito dos seguintes níveis dos sistemas de informação.
5)No contexto de Metodologias de Desenvolvimento de Sistemas, podemos definir que metodologia pode ser entendida como:
a)Uma dissertação sobre a maneira de se utilizar um conjunto coerente e coordenado de métodos para atingir um objetivo, de modo que se evite, tanto quanto possível, a subjetividade na execução do trabalho.
b) Um procedimento a ser adotado para se atingir um objetivo. Para tanto, o método se vale de um conjunto de técnicas.
c)Um modo apropriado de se investigar sistematicamente um determinado universo de interesse ou domínio de um problema. Para se expressar, uma técnica faz uso de uma notação.
d)Um conjunto de caracteres, símbolos e sinais formando um sistema é a melhor maneira de se resolverem os problemas da atividade de desenvolvimento. Deve ser definido o ciclo de vida do sistema adotado, ou seja, quais as fases de trabalho a serem executadas.
6)Quais as técnicas adotadas em uma metodologia paradefinir quais as fases de trabalho previstas no desenvolvimento de sistemas? 
7)Quais as ferramentas adotadas para definir a metodologia de Desenvolvimento de Sistemas?
8)Quais as principais ferramentas de modelagem utilizadas na fase de análise de sistemas por as seguintes técnicas:
a)Análise Tradicional
b)Análise Estruturada
c)Análise Essencial
9)Quais as principais atividades executadas em um processo de levantamento de requisitos de análise de Software.
10)Quais as principais técnicas de especificação?
11) Faça o relacionamento a seguir:
a)árvore de decisão
b)pseudocódigo.
c)português estruturado
d)Tabela de decisão
( )Uma forma textual alternativa, e mais popular, da se descrever mini espécies, quase idêntica ao português estruturado, porém mais próxima das linguagens de programação.
( ) É uma maneira de expressar, em forma de tabela, qual o conjunto de condições que é necessário ocorrer para que um determinado conjunto de ações deva ser executado.
( ) É uma representação de uma tabela de decisão sob a forma de uma árvore. Tem a mesma utilidade da tabela de decisão. 
( ) Constitui-se em uma versão adaptada de nosso próprio idioma, com ênfase em algumas classes gramaticais (no caso, verbos, de preferência no modo imperativo) acrescida de construções típicas das estruturas de controle existentes nas linguagens de programação (sequências, decisões e repetições).
12)Como é composto uma tabela de decisão em um DFD ?
13)Faça uma comparação entre as Técnicas de especificações abaixo ,para descrever como elas são representadas em um DFD.
	PORTUQUÊS ESTRUTURADO
	PSEUDOCÓDIGO
	
	
3. FERRAMENTAS DE MODELAGEM
	Como parte dos requisitos do sistema e da atividade de projetos, o sistema precisa ser modelado como um conjunto de componentes e de relações entre esses componentes. Frequentemente a modelagem de software usa algum tipo de notação gráfica e são apoiados pelo uso de ferramentas case. 
	Modelagem de softwares normalmente implica a construção de modelos gráficos que simbolizam os artefatos de software utilizados e seus inter-relacionamentos. Uma forma comum de modelagem de programas procedurais (não orientados a objeto) é através de fluxogramas, enquanto que a modelagem de programas orientados a objeto normalmente usam a linguagem gráfica UML(Linguagem de Modelagem Unificada) a qual os fabricantes líderes de modelagem estão dando suporte. Na criação de sistemas com qualidade é necessário a utilização de uma boa metodologia para a modelagem tanto do software, como de seu banco de dados. Algumas ferramentas já auxiliam na automação da escrita de código e na implementação da estrutura dos bancos de dados. Os banco de dados são modelados através do modelo de Entidade Relacionamento. O principal objetivo é facilitar o projeto de banco de dados, possibilitando especificar a estrutura geral do banco de dados. Funciona para modelos conceituais relacionais, objeto-relacionais ou orientado a objetos. As ferramentas de modelagem, surgiram para facilitar a criação dos modelos, as mais avançadas permitem a geração de uma parte do código-fonte do software a partir do modelo e até a geração do banco de dados a partir do modelo de entidade relacionamento.
3.1 O diagrama de Fluxo de Dados (DFD)
	Uma importante perspectiva a ser descrita a respeito de um sistema de informações é a de suas funções. Afinal de contas, todo sistema de informações armazena e transforma dados de entrada em dados de saída. Estas transformações são realizadas pelas suas funções.
	Todo modelo funcional de um sistema pode ser visto como sendo formada por uma representação gráfica - uma rede de funções ou processos interligados-, acompanhada de uma descrição de cada função e das suas interfaces. A representação gráfica do modelo funcional costuma ser expresso através de um diagrama denominado diagrama de fluxo de dados, abreviadamente, DFD.
	Um diagrama de fluxo de dados é uma forma gráfica de mostrar a interdependência das funções que compõem um sistema, apresentando fluxos de dados entre elas. Mostra ainda os arquivos lógicos de dados, que são denominados depósitos de dados, como veremos mais adiante, bem como as entidades externas, denominação dada tanto à origem dos fluxos de dados que chegam ao sistema, como ao destino dos fluxos que delem partem.
	Portanto, precisamos definir cada componente do DFD. Começaremos, na seção seguinte, definindo o que vem a ser uma função.
3.1.1 O Conceito de Função
	Idealmente, podemos definir uma função de um sistema analogamente de caixa-preta encontrando na literatura de algumas modalidades de engenharia. Uma caixa-preta pode ser entendida como uma caixa onde:
· há ligações de entrada e de saída da caixa;
· Conhecem-se os elementos de entrada da caixa
· Conhecem-se os elementos de saída da caixa;
· Sabe-se o que a caixa realiza (o que a caixa faz para que, a partir dos elementos de entrada, sejam produzidos os elementos de saída);
· Não se precisa conhecer como a caixa realiza suas operações e nem em que ordem.
	Desta forma, uma função pode entendida como um componente de um sistema onde somente os dados de entrada e os dados de saída são conhecidos. Não se conhece explicitamente nada a respeito do processo interno de transformação dos dados de saída. As funções representam as ações que o sistema executa. Ressalte-se que, em qualquer sistema de informações, nem todas as funções são automatizadas; sempre teremos funções que serão executadas manualmente. Isto significa que devemos representar todas as funções, independentemente de maneira como serão executadas. Convém enfatizar que estamos falando de funções de transformação de dados. No texto deste livro, usaremos às vezes, a palavra “processo” como sinônimo de função.
3.2 O Fluxo de Dados
	Imagine uma tarefa bem simples, com/o, por exemplo, o preenchimento manual de um formulário denominado NOTA DE DÉBITO. Neste caso, podemos dizer que a função a ser executada é PREENCHER NOTA DE DÉBITO. Conforme dissemos, para que a função seja executada, é necessária que haja dados de entrada; no caso, um formulário de nota de débito em branco. A saída desta função será uma nota de débito preenchida. O diagrama a seguir representa esta situação:
	Nota de débito			 Preencher 		Nota de débito
	em branco			nota de débito		preenchida
	Na figura anterior, a função está sendo representada por uma forma oval, com uma seta de entrada e uma de saída. As setas estão representando o que chamaremos de fluxo de dados de entrada e de saída. Esta denominação tem por objetivo dar a idéia de dados em movimento. Fluxos de dados são condutos que levam informação de um ponto de sistema para outro; mostram como os dados fluem através do sistema, o caminho percorrido pelos dados no sistema para outro; mostram como os dados fluem através do sistema, o caminho percorrido pelos dados no sistema. e não o suporte material onde um fluxo de dados representa um conjunto de dados e não o suporte material onde identificamos o conjunto de dados. Trata-se de fluxo de dados e não de fluxo de material. Portanto, não devemos confundir a nota de débito com o formulário onde os dados são preenchidos. Quando estamos escrevendo no fluxo de dados “Nota de débito” estamos nos referindo ao conteúdo do formulário (os dados formulário) e não ao formulário em si.
	Se acrescentarmos ao nosso pequeno sistema a função DIGITAR NOTA DE DÉBITO, teremos o seguinte diagrama:
 (
Digitar nota de débito
) (
Nota de
débito
preenchida
)
 (
Nota de débito
digitada
) (
Preencher
nota de débito
) (
Nota de débito
em branco
)			
3.3Os Depósitos de Dados
	No DFD anterior, temos duas funções em sequência, onde a saída da primeira função é a entrada da segunda. Desta forma a entrada da função DIGITAR NOTA DE DÉBITO é a saída da função PREENCHER NOTA DE DÉBITO. Assim sendo, para que a função DIGITAR NOTA DE DÉBITO seja executada antes dela.
	Podemos então perguntar: para que a 2º função seja executada, é necessário que a 1º função seja executada imediatamente antes? É fácilresponder que não, pois, na verdade, o que precisamos para executar DIGITAR NOTA DE DÉBITO é do formulário NOTA DE DÉBITO preenchido.
	Evidentemente, podemos preencher um formulário em um determinado momento, guardá-lo e, num tempo posterior, digitá-lo. Queremos representar dados que vão ficar armazenados como num arquivo.
	Ao conjunto de dados armazenados denominaremos depósito de dados. Constituem a memória do sistema. Note que, em vez de representar um determinado conjunto de dados que estejam em movimento, é o caso dos fluxos de dados, devemos criar uma maneira de representar dados em estado de repouso. Para tanto, usaremos a representação adiante.
 (
Nota de
débito
digitada
) (
Nota de
débito
preenchida
) (
Nota de
débito
preenchida
)
 (
Digitar nota de débito
) (
Preencher
nota de débito
) (
Nota de débito
em branco
)
	Uma das maneiras usadas para identificar num DFD os pontos de retenção de dados, locais onde os dados estão armazenados, ou seja, os depósitos de dados, é através de duas barras paralelas, em posição vertical ou horizontal. Portanto, uma determinada função (PREENCHER NOTA DE DÉBITO) produz como saída um determinado conjunto de dados. A seguir, uma outra função (DIGITAR NOTA DE DÉBITO) obtém (lê) como dados de entrada o conteúdo do depósito de dados nota de débito preenchida e produz como saída um outro conjunto de dados (nota de débito digitada), que é conduzido pelo fluxo de dados nota de débito digitada. Vale sublinhar que estamos nos referindo a depósitos de dados a não a arquivos físicos. Estamos nos referindo às estruturas de dados lógicas e não aos meios físicos (fichários, arquivos magnéticos etc.) que possam vir a ser usados na fase de implementação para suportá-las.
3.4 As Entidades Externas
	Até aqui, já vimos como representar uma função, suas entradas e suas saídas, bem como dados que devam ser armazenados para posterior utilização. Entretanto, todo sistema está inserindo em algum ambiente com o qual ele interage, de onde partem os fluxos de dados de entrada e para onde vão os fluxos de dados de saída do sistema. Mas o que se entende por ambiente?
	Um ambiente de um sistema pode ser entendido como o meio externo ou em torno do sistema. É delimitado pelos elementos externos que exercem influência sobre o comportamento do sistema.
	Se observarmos o pequeno sistema que descrevemos, podemos perguntar:
	*De onde vem o fluxo de dados notas de débito?
	*Para onde vai o fluxo de dados nota de débito digitada?
	De modo a responder às perguntas acima, precisamos representar os elementos externos, que enviam e recebem informações do sistema. A esses elementos denominaremos terminais ou entidades externas. São as fontes ou destinos dos fluxos de dados que chegam e saem do sistema com o ambiente em que ele está inserido. Uma entidade externa pode ser, por exemplo: um órgão ou uma atividade de uma empresa ou entidade governamental, um outro sistema etc.
A ilustração de tais elementos é apresentada a seguir:
 (
DEPARTAMENTO DE COBRANÇA
)
 ARTAMENTO				
	DE					
 COBRANÇA		Preencher				 Digitar
	Nota de débito	nota de	 Nota de débito nota de débito nota de nota de débito
 (
 SISTEMA
 DE
 COBRANÇA
)	em branco 	débito preenchida preenchida débito digitada
																	
									
										
						
	Na figura anterior, usamos uma das maneiras de representar as entidades externas. No caso, quadriláteros, normalmente, retângulos ou quadrados.
	A seguir, apresentamos um DFD um pouco maior onde se podem ver todos os seus elementos componentes:
					CLIENTE	Lista de compras		 CADASTRAR
										 LISTA DE
DIRETORIA									 COMPRAS
				LISTA DE COMPRAS		 Lista de compras
	Lista
	de		item de compra
	demanda
 EMITIR
 LISTA DE			Produto		PRODUTOS	Produto	 CADASTRAR
 DEMANDA									 PRODUTOS
 (
RAZÃO
SOCIAL
)	Razão										
 (
LISTA DE
PRODUTOS
)	social									Lista de											
FORNECEDORES	Fornecedores	 CADASTRAR		Pedido de 	FORNECEDOR
					FORNECEDORES	Cadastramento
								Fornecedores
Atividade:
a)Quais os elementos componentes de um DFD?
-funções ou processos;
-fluxos de dados;
-depósitos de dados;
-entidades externas.
b) Um DFD apresenta componentes externos (terminais ou entidades externas) e componentes internos (funções, fluxos de dados e depósitos de dados).
c) Um DFD apresenta componentes ativos (as funções) e componentes estáticos (depósitos de dados).
d) Um DFD pode ser visto como um modelo que apresenta as funções de um sistema
e) As informações de um sistema podem ser apresentar em termos estáticos (depósitos de dados) ou em movimento (fluxo de dados).
f) Um fluxo de dados liga:
-uma entidade externa a uma função
-uma função a uma entidade externa;
-uma função a um depósito de dados;
-um depósito de dados a uma função.
-uma função a outra função.
ATIVIDADE
1)Em analise de Essencial, como podemos definir o modelo funcional de dados?
2)No modelo funcional, que tipo de representação é utilizada para representar suas funções?
3)Quais os elementos componentes de um DFD?
4)Defina diagrama de fluxo de dados .
5)Qual é o objetivo principal do Diagrama de Fluxo de Dados (DFD)?
6)O que representam os fluxos de dados de um diagrama de fluxo de Dados?
7)Nos Diagramas de Fluxo de Dados (DFD) , que tipo de notação é utilizada para representar seus componentes ?
8)Nos Diagramas de Fluxo de Dados (DFD) , o que são os Depósitos de Dados?
9) Que regras deveremos adotar para a construção de DFD?
10)De acordo com o DFD da figura abaixo:
Identifique:
a)Quais são os processos deste DFD? E quais são as entidades externais? 
b)Quais são os depósitos de dados deste DFD? E quais são os fluxos de dados? 
c)Existem fluxos de dados inválidos neste DFD? Quais são eles? Por que eles são inválidos? 
11) O que significa a seguinte afirmação: “A continuidade do fluxo de informação deve ser mantida entre os diferentes níveis de detalhamento (refinamento) de um DFD”?
12) Descreva o funcionamento do processo mostrado no DFD parcial dado a seguir
13) Verifique quais os erros existentes nos trechos de DFD a seguir
14) Identifique no DFD a seguir cada componente e tente, usando as denominações dadas aos componentes, avaliar seu objetivo
15) DFD – diagrama de fluxo de dados: Analise o seguinte DFD e responda às questões colocadas
a) com base no DFD representado, indique se este possui alguma incorreção de
representação.
b) refaça o DFD, com as correções que achar necessárias.
c) para o arquivo de dados clientes e a entidade FORNECEDOR descreva a respectiva entrada de dados no dicionário de dados.
4 DIAGRAMA DE CONTEXTO
	
	Se considerarmos que todo sistema está circunscrito a um universo de interesse e que cada entidade extrema estabelece uma fronteira entre o sistema e o ambiente em que ele está inserido, poderemos afirmar que uma única possível representação de um sistema é aquela em que ele apresenta como uma única grande função, cercada pelas entidades externas que com ele interagem. Por intermédio de fluxos de dados.
	Para ilustrar esta idéia, voltemos ao sistema que se suponha a produzir o fluxo de dados nota de débito digitada. Se observarmos a figura a seguir, podemos com, por exemplo, uma linha dupla estabelecer a fronteira do sistema:
 (
DEPARTAMENTO 
DE
 COBRANÇA
)						
					
		
Preencher		
 (
Nota de débito
digitada
) (
Nota de débito
preenchida
)
 (
Digitar nota de débito
) (
Nota de débito
preenchida
) (
Preencher
nota de débito
) (
Nota de débito
em branco
)
 (
SISTEMA DE COBRANÇA
)								
		
					
Como consequência, pode-se expressar tal sistema como o diagrama:
DEPARTAMENTO Obter SISTEMA
 DE Nota de débito nota de Nota de débito DE
 COBRANÇA em branco débito digitadaCOBRANÇA
	O diagrama anterior, que representa apenas um sistema e suas interfaces, é denominado Diagrama de Contexto.
	Se adotarmos o mesmo procedimento para o outro exemplo apresentado, teremos:
					CLIENTE Lista de compras CADASTRAR
LISTA DE
COMPRAS
DIRETORIA LISTA DE COMPRAS Lista de Compras
Lista
De item de compra
demanda
 Emitir
 Lista de produto PRODUTOS produto CADASTRAR
 Demandas				 				 PRODUTOS
 Razão 
 Social lista de 
										produtos											
FORNECEDOR fornecedores 
 Pedido de 
					CADASTRAR
					FORNECEDOR 
		 					 Cadastramento de
							 fornecedores
 FORNECEDORES 
E chegaremos ao seguinte diagrama de contexto:
				CLIENTE	
					
 Lista de Compras			
DIRETORIA
		Lista de Sistema de 
 demanda Acompanhamento
 da Demanda
 de Produtos					
										Lista de
										produtos
					Pedido de
					 Cadastramento de FORNECEDOR	
 fornecedor	
	
Ao analisar as duas situações mostradas, podemos concluir que:
a) O sistema “Obter Nota de Débito Digita” pode ser decomposto em duas funções: 
	1)Preencher Nota de Débito;
	2)Digitar Nota de Débito.
b) O “Sistema de Acompanhamento de demanda de Produtos” pode ser decomposto em quatro funções:
	1)Cadastrar Produtos;
	2)Cadastrar Fornecedores;
	3)Cadastrar Lista de Compras;
	4)Emitir Lista de Demanda.
Como consequência, podemos concluir que:
	-Um DFD é uma representação de um sistema sob a forma de uma rede que mostra os componentes ativos do sistema e as interfaces de dados entre eles.
	-Todo sistema pode, a partir do Diagrama de Contexto, ser decomposto em diversas funções que se interligam. Note que as entidades externas no diagrama expandido (DFD que apresenta as funções do sistema) são as mesmas do Diagrama de Contexto, no qual, entretanto, são mostrados apenas os fluxos de dados que representam a interface do sistema com as entidades externas.
	-para cada função do sistema, podemos aplicar esse mesmo principio e decompô-la em funções mais simples, ou seja, sub funções.
	Todo sistema pode ser representado como um grande processo, interagindo como o ambiente em que está inserindo. Isto significa que a primeira visão de um sistema é o diagrama de contexto.
	Como desenhar um diagrama de contexto?
	Passo nº1) Desenhar um único processo ou função para representar o sistema inteiro.
				
					CIA.
				END- VIDADA
Passo nº2) Desenhar todas as entidades externas que se comunicam com o sistema.
									
									DEPTO.
									PLANE-
									JAMENTO
	CLIENTE
				 CIA.
			 END- VIDADA
 FORNE DEPTO-
 CEDOR					 FINANCEIRO
Passo nº3) Para cada entidade externa, desenhar o fluxo de dados que mostra sua comunicação com o sistema
 PAGAMENTO
 CLIENTE
									 DEPTO.
									 PLANE-
CLIENTE PEDIDO						 JAMENTO
 CLIENTE
 CIA.. RELATÓRIO
	 FATURA-CLIENTE END- VIDADA FINANCEIRO
 ENCOMENDA COMISSÃO DOS
							 VENDEDORES
 FATURA DO
	 FORNECEDOR					 DEPTO.
FORNE							 FINAN-
CEDOR 		 PAGAMENTO CEIRO
			 FORNECEDOR
	Há quem discuta se, em um Diagrama de Contexto, Já poderiam aparecer depósitos de dados ou não. Particularmente, preferimos não apresentá-los neste nível. Acreditamos que em um Diagrama de Contexto deve-se representar apenas um sistema e suas interfaces com as entidades externas.
5 NIVELAMENTO E BALANCEAMENTO
	Do que nos foi apresentado até agora, somos levados a considerar que estamos diante de um processo de decomposição sucessiva e hierárquica, que toma a forma de uma rede onde cada nó (função ou processo) pai pode ser decomposto em outra rede de funções filhas com os respectivos fluxos de dados e depósitos de dados do nível imediatamente inferior, e assim sucessivamente, até que não possa mais ser decomposta. A função que não possa mais ser decomposta é denominada função primitiva, ou primitiva funcional. Trata-se de uma função básica ou atômica - que não mais possa ser subdividida. Em resumo, todo DFD pode ser decomposto em DFDs de nível inferior, recursivamente, até alcançarem-se as primitivas funcionais. Trata-se de uma fatoração hierárquica. A ilustração a seguir nos mostra esta situação.
 E1							E3
 FD1 			FD7
			 SISTEMA						Nível
 FD2						FD8		Contexto
 E2							E4
			 SISTEMA 
 E1						 E3
 FD1
			 P2 FD7
 FD5 Nível 0
 FD6 P4
 E2 FD2 FD3
 P1 FD4 P3 FD8 E4
P3
 P2
 FD6 P3.1 P3.3
									Nível 1
 P1 FD4 P3.2
 P3.4 FD8 E4 
Apresentamos, inicialmente, um Diagrama de Contexto do sistema, onde:
-as entidades externas estão representadas por E1, E2, E3 e E4;
-os fluxos de dados são representados como FD1, FD2, FD7, e FD8.
No passo seguinte, é exibido o primeiro nível de particionamento do sistema, onde:
-os processos (funções) do sistema são representados por P1, P2, P3, e P4.
-além dos fluxos de dados já apresentados, aparecem ainda FD3, FD4, FD5 e FD6
Em seguida, é ilustrada a decomposição do processo P3,onde:
-aparecem processos com as denominações P3.1, P3.2, P3.4.
-é apresentado ainda um depósito de dados entre os processos P3.1 e P3.3.
-aparecem entidades externas com as denominações P1, P2 e E4.
Algumas observações se fazem necessárias:
a) Um sistema de tamanho razoável, normalmente, não deve ser modelado em único DFD, pois o modelo poderia ficar ininteligível.
b)Para resolver este problema, são construídos vários DFDs representando o sistema em sucessivos níveis de detalhe, chamados níveis de abstração. A esta estratégia costuma-se chamar nivelamento. Na figura anterior foram apresentados três níveis de abstração. Cada DFD representa o detalhamento (explosão) do DFD de um nível imediatamente superior. Uma maneira de identificar os níveis de abstração é numerá-los em ordem sequencial, tal como nível zero, nível 1, nível 2, nível3 etc.
	A abordagem em que efetuamos a decomposição do sistema, partindo do diagrama de contexto (nível mais geral) edescendo passo a passo a níveis mais baixo (mais detalhados), é denominada abordagem “top-down”. Foi a abordagem preconizada pela técnica de análise denominada Análise Estruturada, muito popular desde o final da década de 1970 até meados da década de 1980. Uma outra abordagem possível, oposta à “top down”, denominada “bottom-up” parte do nível mais detalhado para o nível mais geral. Outras abordagens também conhecidas são as denominadas “outside-in”, inside-out”, ou ainda “midle-out”.
	Numa decomposição do tipo “top-down”, é possível que, em um determinado nível algumas funções já sejam primitivas funcionais, enquanto outras ainda não o são. Estas ainda darão origem a DFDs mais detalhados (de nível mais baixo). Uma imagem que pode ser adotada é a de se considerarem as primitivas funcionais como sendo átomos que ao se agregarem vão formar as moléculas de uma substância.
	É conveniente que, em cada nível de abstração, as funções estejam em grau de detalhamento próximo, ou seja, não convém que em um dos níveis do DFD uma das funções ainda precise ser decomposta em sub-funções de muitos níveis de abstração inferiores até chegar à primitiva funcional, enquanto outras funções do mesmo DFD já são primitivas. Cada DFD deve apresentar um nível de detalhe equilibrado. Os processos que tratam de rotinas de erros e de exceções devem ser expressos nos níveis mais baixos.
	Para alguns autores, cada nível de DFD deve ter de 5 a 9 funções. Segundo os defensores desta idéia, esta é uma boa maneira de se tratar a complexidade do sistema, visto que um DFD com inúmeras funções tornar-se-ia de difícil leitura.
	c)Sempre que ocorre particionamento, deve ser garantida a consistência entre as entradas e saídas de cada dois níveis de particionamento sucessivos. Em outras palavras, há uma espécie de conservação de energia ou conservação dos dados, no sistema. A esta necessidade costuma-se chamar balanceamento.
	Ao particionar um processo, qualquer fluxo de dados, depósito de dados ou entidade externa que apareça a ele ligado no nível de cima tem de aparecer no DFD do nível imediatamente inferior.
	Do ponto de vista de quem observa o sistema a partir do exterior, não pode haver fluxos de dados de entrada ou de saída no nível inferior que não existam no de cima. Tanto no Diagrama de Contexto como no nível imediatamente inferior, temos os mesmos fluxos de dados servindo de interface entre o sistema e o seu exterior, ou seja F1, F2, F7, e F8. Da mesma forma, no particionamento do processo P3, notam-se os mesmos fluxos de dados de entrada e saída, no caso, FD6, FD4 e FD8. 
	d) Ao particionarmos um processo, como é o caso de P3, uma boa conduta é reconhecer que, do ponto de vista de P3, os processos P1 e P2 são considerados “entidades externas”. Esta conduta nos ajuda a garantir a consistência entre os diversos níveis de particionamento. Note que estamos chamando P1e P2 de entidades externas, apenas em relação à explosão do processo P3; mas não para o sistema como um todo.
	e)A maneira usada para expressar a correspondência entre os níveis pais e níveis filhos da especificação estruturada foi a designação numérica mostrando a que diagrama pai corresponde um diagrama filho. Em consequência, P3.1, P3.2 e P3.3 são processo filhos do processo pai P3. Se, por exemplo, o processo P3.2 ainda não fosse uma primitiva funcional, seus processos filhos seriam numerados por P3.2.1, P3.2.2, P3.2.3, e assim por diante. Ao analisar a figura anterior, três problemas afloram:
	a)Qual o critério de particionamento de uma função que deve ser usado?
	Por ora, podemos responder que, à luz dos conhecimentos atuais sobre este assunto, o melhor critério é o de particionar uma função de tal forma que nos DFD resultante as sub-funções componentes tenham a mínima quantidade de interfaces possível. Voltaremos a este ponto mais tarde, quando, esperamos, este assunto ficará mais claro.
	b)O modelo das funções compõe-se apenas de uma representação diagramática? 
	Não. A especificação do modelo das funções (especificação funcional) inicia-se com a decomposição do diagrama de contexto em sucessivos DFDs, cada vez mais detalhados, até que se chegue às funções primitivas. Apenas os desenhos não são suficientes para que se possa compreender o modelo das funções. Dessa maneira, falta ainda descrever o conteúdo dos fluxos de dados e dos depósitos de dados. Isto se faz através de uma linguagem de descrição apropriada para esta necessidade, a qual veremos no momento oportuno. Por outro lado, ao de chegar às funções primitivas, passa-se a especificar de forma descritiva, fazendo uso das técnicas estruturadas de especificação.
	Em uma especificação funcional, apenas as descrições das funções primitivas são apresentadas e são chamadas mini especificações (miniespecs). Mais adiante veremos como se faz isto.
	c) Até quando se deve continuar particionando as funções?
	Poderíamos dizer que cada nó pai deva ser particionado em uma rede de nós filhos até que o nível desejado de detalhe seja alcançado, e ai estaríamos diante de funções primitivas. Entretanto, qual deve ser o nível de detalhe desejado? Aqui reside um problema, pois não há uma medida precisa sobre se uma função ainda deve ser decomposta ou não. Como regra puramente prática, pode-se dizer que uma função primitiva é aquela que:
	-pode ser descrita em apenas uma página, que esta página represente a descrição de um pequeno procedimento manual ou um módulo de um programa de computador, ou;
	-sua descrição, em pseudocódigo, não ultrapassa 50 a 100 linhas.
	Para armazenar as descrições mencionadas, é necessário um procedimento específico para este objetivo. Isto é apresentado no capítulo seguinte.
6 O DICIONÁRIO DE DADOS
	
	Conforme dissemos, o modelo funcional é composto de uma representação gráfica e uma descrição dos componentes do modelo-entidades externas, funções, fluxos de dados e depósitos de dados. Logo, uma vez identificados os componentes do modelo, devemos descrevê-los. Para tanto, conforme proposto pela literatura, é usado um sistema, que vai guardar informações sobre os componentes dos sistemas. Para tanto, conforme proposto pela literatura, é usado um sistema, que vai guardar informações (metadados) sobre os sistemas de nosso interesse, denominado dicionário de dados. Um dicionário de dados é um repositório de informações sobre os componentes dos sistemas. Para descrever os componentes de sistema, devemos adotar uma linguagem apropriada. Várias formas podem ser usadas para, por exemplo, apresentar os dados de um fluxo de dados. Utilizaremos os seguintes símbolos:
	SÍMBOLO
	SIGNIFICADO
	=
	é equivalente a 
	{ }
	Ou
	*(min-max)
	Repetições
	[ ]
	Opcional
	@
	Chave
	% %
	Comentário
6.1 Descrições dos Fluxos de Dados
	Seja mostrar a composição do fluxo de dados denominados FATURA-CLIENTE de o DFD a seguir:
		 PAGAMENTO DO CLIENTE DEPTO.
	CLIENTE PLANEJA-
			 PEDIDO-CLIENTE MENTO
 RELATÓRIO
 FINANCEIRO
 CIA.
 FATURA-CLIENTE END-VIDADA
 ENCOMENDA COMISSÃO DOS
 VENDEDORES
 FATURA DO 
 FORNECEDOR DEPTO