CAPTULO 1

PRONATEC/SEDUC-PIANLISE DE SISTEMASANLISE DE SISTEMAS

PROGRAMA DE DISCIPLINAESCOLA OFERTANTE:

CURSO: TCNICO EM INFORMTICA

SEMESTRE: ANO:

DISCIPLINA: ANLISE DE SISTEMAS.MDULO: 2C/H TOTAL: 68hC/H SEMANAL: 4h

I Objetivos Conhecer as etapas para desenvolvimento de um software. Conhecer as principais ferramentas de modelagem e estruturao de um projeto de software.

II Contedo ANLISE DE SISTEMAS E A MODELAGEM DE SISTEMAS 10h FERRAMENTAS DE MODELAGEM 6h O DIAGRAMA DE CONTEXTO 8h NIVELAMENTO E BALANCEAMENTO 8h O DICIONRIO DE DADOS 8h A ESPECIFICAO DOS PROCESSOS 12h REGRAS PARA A CONSTRUO DE DFDS 16h

Metodologia Aulas expositivas, tarefas e pesquisas bibliogrficas extraclasses e prticas de laboratrio utilizando recursos computacionais (Hardware e Software) disponveis nos laboratrios didticos de informtica; Pesquisas em grupos e individuais; Seminrios;

Avaliao Provas escritas, seminrios, aulas prticas. Nota valer de 0 (zero) a 10 (dez) pontos e para a aprovao ser necessrio obter nota igual ou superior a 6 (seis) pontos e presena mnima de 75% das aulas.

III BibliografiaGane, Chris / Sarson, Trish - Anlise estruturada de Sistemas. Ed. LTC.SILVA, Nelson Peres. Anlise e Estruturas de Sistemas de Informao. Ed. rica.DENNIS, Alan. Anlise e Projeto de Sistemas. Ed. LTC.WAZLAWICK, Raul. Anlise e Projetos de Sistemas Orientados a Objeto. Ed. Campus.TONSIG, Sergio Luiz. Engenharia de Software: Anlise e Projeto de Sistema. Ed. Cincia Moderna.

Notas de Edio:

O assunto Anlise de Sistemas abordado nessa apostila baseado em vrios trabalhos publicados nos Anais do Congresso XV Nacional de Informtica Dependncias funcionais e dependncias de incluso: Aplicaes ao projeto lgico de Banco de dado, Modelagem Conceitual de dado: da teoria pratica, A integrao de dados e funes no desenvolvimento de sistemas, Modelagem conceitual de dados: Uma comparao entre abordagens, todos de autoria Severino Pompilho. Modificamos apenas as notaes utilizadasfazendoadaptaes necessrias para facilitar o entendimento. permitida a reproduo total ou parcial desse material, sem o pagamento de direitos autorais, contanto que as cpias sejam feitas e distribudas sem fins lucrativos. Vale salientar que os materiais foram adaptados para fins pedaggicos no configurando assim tentativa de descaracterizao do material produzido pelos autores. Por fim, a equipe de elaboradores espera que a apostila ANLISE DE SISTEMAS esteja dentro dos padres e necessidades dos alunos do PRONATEC/PI.

Contedo1 ANLISE DE SISTEMAS61.1 introduo61.2Problemas no Desenvolvimento de Sistemas61.4 Etapas desenvolvimento software111.5 O Perfil do Analista de Sistemas111.5.1 O Aprendizado e a Comunicao132A MODELAGEM DE SISTEMAS182.1 Tcnicas de Levantamento requisitos de software202.1 O Ciclo de Vida do Sistema222.2 Metodologias de Desenvolvimento de Sistemas253. FERRAMENTAS DE MODELAGEM333.1 O diagrama de Fluxo de Dados(DFD)333.1.1 O Conceito de Funo343.2 O Fluxo de Dados353.3Os Depsitos de Dados363.4 As Entidades Externas37Identifique:404 DIAGRAMA DE CONTEXTO435 NIVELAMENTO E BALANCEAMENTO476 O DICIONRIO DE DADOS526.1 Descries dos Fluxos de Dados536.2 Descrio dos Depsitos de Dados557 A ESPECIFICAO DOS PROCESSOS587.1 Portugus Estruturado597.2 Pseudocdigo627.3 Tabela de Deciso627.4 rvore de Deciso668 REGRAS PARA A CONSTRUO DE DFDS689. REFERNCIAS78

1 ANLISE DE SISTEMAS

1.1 Introduo

O desenvolvimento de software uma atividade de crescente importncia na sociedade contempornea. A utilizao de computadores nas mais diversas reas do conhecimento humano tem gerado uma crescente demanda por solues computadorizadas. importante observar que, associada ao acrscimo da demanda, a evoluo do hardware tem sido mais acentuadas, disponibilizando aos usurios mquinas cada vez mais velozes e com maior capacidade de processamento. Neste contexto, identificou-se, j na dcada de 70, uma situao crtica no desenvolvimento de software, a chamada Crise do Software [Pressman], caracterizadapelos 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 esforos 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 anlise e especificao de requisitos, na qual os requisitos de um sistema so levantados e modelados, para s ento ser projetada e implementada uma soluo (FALBO, 2002).

1.2Problemas no Desenvolvimento de Sistemas

O processo de informatizao das atividades administrativas de uma empresa traz inmeras implicaes, que vo desde mudanas nas rotinas de trabalho at reestruturaes organizacionais, com toda a problemtica que da, invariavelmente, decorre.Em certos casos, devido grande presso exercida pelos usurios, tenta-se resolver o problema da informatizao atravs de uma viso mecanicista de realidade. Esta soluo leva a tentativas de soluo, quase sempre, de natureza instrumental, como acontece quando a direo da empresa convencida por um fornecedor de hardware ou de software que lhe garante ser o produto, por ele vendido, o remdio para todos os males que afligem a empresa. Isto, sem dvida, no costuma dar certo, pois sabemos que a simples aquisio de tecnologia de hardware ou de software no , por si s, suficiente para resolver certos problemas que dependem fundamentalmente de um planejamento estratgico e ttico, obviamente necessrio a uma boa administrao. Antes de escolher qualquer produto, seja hardwareou software, temos de determinar quais so os sistemas de que realmente a empresa necessita e quais so as suas caractersticas. Alis, lembrando o filsofo Plato: Para a nave que no tem nenhum ponto de destino qualquer vento bom (Embora possa haver alguma gratificao no movimento).Em vista disso, a informatizao de uma organizao empresarial deve ter como preocupao o conhecimento de todas as necessidades nos nveis estratgicos, ttico e operacional, no apenas contempladas pelos sistemas atuais mas tambm nos sistemas futuros sejam eles automatizados ou no. Portanto, precisa-se de uma boa quantidade na especificao das necessidades, com descries voltadas para a misso e os objetivos da organizao.A tarefa de especificar os sistemas de informaes que compem uma empresa uma das mais complexas e, em ltima anlise, um processo de soluo de problemas. Para ser bem feita requer no apenas conhecimentos de computaomas boa dose de vrios conhecimentos conexos, por seu carter interdisciplinar.A literatura de informtica cita uma srie de problemas de desenvolvimento de sistemas que so a natureza tcnico-econmica, tais como: produtividade da equipe, correo da especificao, confiabilidade do sistema, manutenbilidade do cdigo-fonte, segurana dos dados, desempenho e portabilidade do sistema. Evidentemente estes so problemas reais e importantes, que requerem um ateno especial. A soluo para estes problemas est na adoo de um tratamento sistemtico que viabilize, seno a sua eliminao, pelo menos a sua minimizao. As metodologias de desenvolvimento de sistema com as que fazem uso das tcnicas aqui apresentadas so um grande passo para resolver estes problemas, como poder ser desejvel para os analistas de sistemas e a questo do aprendizado e da comunicao.Desde os primrdios da informtica, a instalao dos usurios com o atendimento de suas necessidades de sistemas de informao causa de transtornos para os profissionais da rea. Vrios autores internacionais documentaram este fenmeno, valendo citar, por exemplo.H evidncias e agrupamento tericos de que inadequao dos sistemas comum, que os profissionais de informtica tendem, durante a fase de desenvolvimento dos sistemas, a dar maior ateno aos aspectos relativos eficcia ou adequao dos sistemas s necessidades dos usurios. Este tema costumava ser relegado a um plano inferior e, infelizmente, essa ainda tem sido a regra em algumas situaes, hoje em dia, Muitas vezes, encontramossolues brilhantes do ponto de vista do desempenho da mquina, mas que no resolvem o problema do usurio.A conduta a ser adotada durante o desenvolvimento de sistemas deve ser tal que conduza construo de sistemas efetivos, isto , sistemas que no sejam apenas eficientes, mas tambm eficazes; que faam exatamente o que til e necessrio para os usurios particularmente e para a empresa de modo global. Ou seja, que no se d nfase apenas s preocupaes com o custo, mas que, sobretudo, atente-se para aderncia do sistema s necessidades do usurio, parmetro que serve para exprimir seu valor ou utilidade. Podemos dizer que entre as razes pelas quais baixo o grau de satisfao dos usurios com os seus sistemas automatizados sobressai inadequao da abordagem utilizada para a fase de desenvolvimento para os usurios.Entre as principais deficincias encontradas na maioria das abordagens utilizadas no desenvolvimento de sistemas est o fato de elas enforcarem apenas aspectos tcnico-econmicos em problemas que, normalmente, tm forte componente psicossocial. Este , com frequncia e indevidamente, negligenciado. Um claro exemplo das dificuldades enfrentadas pela tentativa de utilizao de enfoque apenas tcnico-econmico est na proposta do uso de banco de dados como fator de integrao de empresa. Tal proposta, embora muito atraente do ponto de vista tcnico-econmico de difcil implementao pelo menos quando se quer o preconizado na teoria. Note que estamos nos referindo a banco de dados como ponto-chave da integrao dos sistemas, desde o seu nvel de especificao conceitual, e no apenas como soluo de problemas de armazenamento de dados. Isto acontece justamente porque um dos famosos donos do dado, o que, sem dvida, no pode ser resolvido sem uma anlise do aspecto social da organizao. Dados gerncias ou operacionais, quando representando informaes importantes, so fontes de disputa de poder. Em razo desta constatao, apenas um especialista em computadores.A partir do advento dos microcomputadores, a tecnologia de hardwaree de software evoluiu rapidamente, e hoje so oferecidas ao prprio usurio enormes facilidades para o uso desses recursos. Em auxlio aos analistas, o avano tecnolgico 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 especificao dos requisitos do sistema e dos negcios de empresa do que apenas para o conhecimento da programao e operao de mquinas.

1.3 Sistemas de Informao nas Organizaes.

Sistemas de informao atualmente servem em todas as reas e nveis dasorganizaes, sendo considerados como ferramenta essencial para o sucesso de suas atividades. Isso nos permite classific-los de acordo com a responsabilidade assumida por seus usurios dentro da organizao em quatro tipos principais (LAUDON, 2001). Sistemas de nvel operacional, que tratam da execuo, acompanhamento e registro da operao diria da empresa, sendo geralmente sistemas fortemente transacionais. Exemplos so sistemas de vendas, folha de pagamento, etc. Sistemas de nvel de conhecimento, que suportam as pessoas que trabalham com dados e conhecimento dentro da organizao. Exemplos simples de sistemas desse tipo so os processadores de texto e as planilhas eletrnicas. Sistemas de nvel gerencial, que utilizam dados da operao e outros dados inseridos nesses sistemas para permitir a obteno de informaes que permitam a gerncia da empresa, suportando a tomada de decises, o controle e o monitoramento. Sistemas de nvel estratgico, que so sistemas destinados a decises de mais alto nvel (efeito estratgico) e utilizam dados de todos os sistemas anteriores, normalmente de forma agregada e processada, sendo utilizados pela alta gerncia (LAUDON, 2001).

Figura 1: Nveis dos sistemas de informao dentro de uma organizao (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 representao (POMPILHO, 2002).Assim, considerando que uma organizao empresarial pode ser entendida como sendo um sistema, ele pode ser bem compreendida se apresentarmos trs modelos que, conceitualmente, a representam, a partir de trs perspectivas que se complementam: Um modelo funcional, que apresenta uma viso estruturada das funes ou dos processos que compem a organizao; Um modelo de dados, que apresenta uma viso dos dados que sero armazenados para serem usados pela organizao; Um modelo de controle, representando as transformaes de controle e uma viso do comportamento da organizao em relao aos seus diferentes estados vlidos, cada um dos quais sendo caracterizado por uma determinada resposta fornecida quando a organizao estiver sujeita a certo conjunto de estmulos.

1.4 Etapas desenvolvimento software

Um completo entendimento dos requisitos do software essencial para o sucesso de um esforo de desenvolvimento de software. A atividade de anlise e especificao de requisitos um processo de descoberta, refinamento, modelagem e especificao. O escopo do software definido no planejamento do projeto refinado em detalhe, as funes e o desempenho do software so especificados, as interfaces com outros sistemas so indicadas e restries que o software deve atender so estabelecidas. Modelos dos dados requeridos, do controle e do comportamento operacional so construdos. Finalmente, critrios para a avaliao da qualidade em atividades subsequentes so 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 especficas de um cliente ou grupo de clientes.No desenvolvimento de software realizamos as atividades de descoberta das necessidades e de criao do produto de software propriamente dito. Podemos dividir as atividades do processo de desenvolvimento em alguns grandes grupos: Atividades de Anlise, cuja finalidade descobrir o que deve ser feito; Atividades de Projeto, cuja finalidade descobrir como o software deve ser feito; Atividades de Implementao, cuja finalidade produzir o produto de software de acordocom as especificaes 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 verificaes (XEXO,2007).

1.5 O Perfil do Analista de Sistemas

Para ter boa probabilidade de sucesso o analista de sistemas deve possuir uma formao que vai alm 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 anlise de sistemas de informao administrativos: Comunicao: entendida como capacidade para ouvir, redigir e expor idias com clareza e preciso, aprender e expressar o contedo do aprendizado com facilidade; Capacidade de anlise: entendida como aptido para realizar operaes mentais com abstraes sobre o recorte da realidade em estudo. Possuir umaviso sistemtica e critica do contexto em anlise, alm de habilidade para distinguir e conceituar categorias de significados de noes concretas e abstratas associadas aos negcios da empresa; Conhecimento da rea usuria: entendido, principalmente, como aquele tipo de conhecimento que no pode ser obtido atravs de treinamento mas adquirido por meio de experincia pessoal ao longo da vivncia com operaes da empresa; Capacidade de negociao: entendida como habilidade em obter resultado desejado, ainda que em condies adversas, e capacidade de administrar conflitos de interesses interpessoais que surjam durante o trabalho em grupo; Administrao de projetos: entendido como noes sobre alocao de tempo e recursos humanos, financeiros e materiais necessrios a projetos, nos quais participam pessoas de formaes diferentes, num empreendimento de caracterstica interdisciplinar, procurando sempre a efetividade, garantindo no s a eficcia como tambm a eficcia do processo de obteno dos resultados a serem alcanados; Conhecimento Tcnico: entendido como capacidade de especificar sistemas de informao, principalmente nas suas fases de nvel de abstrao mais alto, utilizando ferramentas de modelagem, especialmente as adotadas pela tcnica de anlise essencial. Pode ser til, ainda, o conhecimento das estruturas lgicas do Sistema Gerenciador de Banco de Dados utilizados pela empresa;Os requisitos acima colocados constituem o perfil considerado por ns como ideal. Reconhecemos, todavia, a dificuldade de se terem disposio profissionaiscom essa capacitao. Para iniciar-se na atividade de anlise de sistemas, no condio indispensvel a proficincia em todas as habilidades mencionadas. As funes de analista, projetista e programador so, s vezes, confundidas. Para esclarecer este ponto, podemos dizer que, a rigor, o papel do analista de sistemas especificar quais so os requisitos do sistema do ponto de vista eficcia, 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 instrumentao que ser usada para chegar a esse objetivo. Por sua vez, o projetista tem um papel voltado para eficincia, isto , voltando para a obteno do melhor desempenho individual dos componentes do sistema. Por fim, o papel do programador construir (implementar) o sistema de acordo com as especificaes feitas pelo projetista.

1.5.1 O Aprendizado e a Comunicao

Para bem realizar a especificao de um sistema de informao, o primeiro passo reconhecer que atividade de desenvolvimento de sistemas , em essncia, um processo de soluo de problemas. E, como tal, esse processo compe-se em de uma fase de aprendizado (entendimento dos requisitos dos sistemas) e outra de comunicao (apresentao, da soluo encontrada para aprovao dos usurios). 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 comea com uma fase de aprendizado. A obteno dos requisitos necessrios ao sistema torna-se bastante dificultada, pois o usurio expe o seu problema em linguagem natural, podendo ainda no ser capaz de expressar adequadamente as suas necessidades. Isto pode resultar em problemas de consistncia ou m interpretao, o que, sem duvida, ir acarretar erros cujaaconsequncia poder ser muito cara. Por tudo isto, trata-se de uma tarefa bastante delicada.A fase do aprendizado de grande complexidade, e vrias so as teorias sobre os mecanismos pelos quais ela se processa. Entre essas teorias, podemos exemplificar:Na primeira etapa, partimos da observao da realidade, tentando obter uma viso global do assunto em estudo. Isto, na verdade, buscado atravs de um processo no-estruturado e tem as caractersticas de uma coleta de conhecimentos, que sero reunidos no tema abordado. a rigor um processo informal, atravs do qual tentamos juntar todos os fatos relevantes a respeito do problema em questo 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(anlise), j partimos da viso global, obtida na fase anterior. Nesta hora, o processo de aprendizagem passa pela construo de uma espcie de maquete, o que consiste em identificar as variveis ou pontos-chave do problema para construo de modelo simplificado com sua estrutura, com seus elementos e relaes, possibilitando, destaque, que ai se faa, tendo como suporte um modelo do problema. Ao final desta fase, o analista j tem uma idia do tudo e de suas partes.A ltima etapa ser, ento, aquela em que se iro propor hiptese de soluo a serem adotadas. a etapa chamada sntese; ao final, tem - se idia de todo o sistema, quais as suas partes e qual a soluo proposta para o problema. Cabe assinalar que, diferentemente de algumas reas de cincia exatas, no estamos tratando de um problema que tenha uma nica soluo correta, mas buscando uma que seja aceitvel entre as solues possveis.Como se pode observar, bastante complexo o processo de aprendizado. Fica fcil 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 especificao. muito difcil prever o tempo que algum vai levar para compreender, com exatido, todos os requisitos de um sistema. Alm disso, o tempo pare se aprender algum assunto varia muito de pessoa para pessoa. A capacidade de aprender com eficincia tambm, em nossa opinio, uma habilidade considerar da importante para os profissionais de desenvolvimento de sistemas. A compreenso do domnio do problema a ser resolvido realmente um ponto crucial da anlise de sistemas se compreendermos bem um problema j tem um grande avano para a soluo.Uma vez terminada a fase de aprendizado, entramos na fase de comunicao com o usurio. Esta fase tambm tem fatores que dificultam. Os principais gargalos num processo de comunicao ocorreram por conta de problemas das seguintes naturezas: Problemas psicolgicos: relacionados com percepo, ateno, motivao, atitudes, memria, hbitos de pensamento; Problemas semiolgicos: relacionados com o emprego de signos e cdigos para comunicar: palavras, gestos, tom de voz, coisas escritas etc. Problemas semnticos: relacionados com os significados das palavras, dos objetos e das pessoas, assim como com sua interpretao; Problemas sintticos: relacionados com a estrutura ou organizao dos contedos e dos significados; Problemas cibernticos: relacionados com retro informao e dilogo, com a quantidade de idias transmitidas por diversos canais e com capacidade destes para levarem sinais;A literatura especfica de desenvolvimento de sistemas at que tem reconhecido o problema da comunicao. Nesta literatura, tm sido apresentadas vrias tcnicas, todas visando minimizar as dificuldades da comunicao entre os desenvolvedores de sistemas e os usurios. Sabemos que o sucesso de um sistema depender fundamentalmente de sua aceitao por parte do usurio. Para tanto, devemos apresentar a soluo proposta a todos os que, de alguma forma, puderem contribuir para a descoberta da soluo mais adequada ao ambiente no qual o sistema ser implantado. Isto implica necessariamente de uma linguagem (forma de expresso) comum a ser usada por profissionais de formaes diferentes, num empreendimento de caracterstica interdisciplinar.

ATIVIDADE

1)Defina anlise de sistemas.

2)A anlise de sistemas um processo de transmisso de conhecimento e, assim sendo, envolvem trs etapas, quais?

3)Qual a importncia da Anlise 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 Informao nas Organizaes?

8)Quais os Nveis dos sistemas de informao dentro de uma organizao? Explique cada um deles.

9)Considerando que uma organizao empresarial pode ser entendida como sendo um sistema, ele pode ser bem compreendido se apresentarmos trs modelos que, conceitualmente, a representam, a partir de trs perspectivas que se complementam, so 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 anlise de sistemas de informao por um analista ?

12)Diferencie as funes dos analistas, projetista e programador nas atividades de analise de sistemas.

13)Para bem realizar a especificao de um sistema de informao, o primeiro passo reconhecer que atividade de desenvolvimento de sistemas , em essncia, um processo de soluo de problemas .Sobre a afirmativa incorreto afirmar que :

a)Esse processo compem-se em de uma fase de aprendizado (entendimento dos requisitos do sistemas) e outra de comunicao (apresentao, da soluo encontrada para aprovao dos usurios).

b)Normalmente, quando um analista inicia o desenvolvimento de um sistema, ele j sabe tudo sobre o sistema a ser desenvolvido. Portanto, o desenvolvimento comea com uma fase de soluo encontrada para aprovao dos usurios.

c)A obteno dos requisitos necessrios ao sistema torna-se bastante dificultada, pois o usurio expem o seu problema em linguagem natural, podendo ainda no ser capaz de expressar adequadamente as suas necessidades. Isto pode resultar em problemas de consistncia ou m interpretao, o que, sem duvida, ir acarretar erros cuja a consequncia 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 especficas de um cliente ou grupo de clientes.

2 A MODELAGEM DE SISTEMASDesde que foi percebido pelos profissionais de informtica que grande parte das deficincias nas especificaes de sistemas era devida problemtica de comunicao, um esforo considervel tem sido realizado no sentido de se superar este problema. Para tanto, construram-se vrias propostas metodolgicas, que enfatizam a necessidade de uma linguagem a ser empregada pelos analistas de sistemas, linguagem essa que pudesse ser compreendida tambm pelos usurios.Dentro desta linha, desenvolveram-se linguagens que passaram a incluir os recursos necessrios para definir as necessidades do usurio, independentemente de qualquer restrio relativa implementao. Ou seja, linguagens de especificao que,se tornem mais inteligveis ao usurio no-tcnico e por outro lado, permaneam suficientemente precisas, para permitir que se produza uma especificao que seja base para um subsequente projeto operacional dos sistemas de informao necessrios.Este tipo de linguagem deve possuir recursos que permitam produzir uma especificao que possa ser apresentada ao usurio e com ele discutida. Um erro muito comum no passado, entre os profissionais de informtica, era a crena de que todas as necessidades de informaes seriam conhecidas apriori pelos usurios. A prtica mostrou que isto no era verdade, o que faz com que est restrio deva ser considerado com devido cuidado na soluo do problema da linguagem.O fato do usurio no saber a priori todos os requisitos do sistema ser construdo no uma caracterstica exclusiva de problemas da rea de desenvolvimento de sistemas. Na verdade, isto comum em qualquer ramo de atividades onde haja complexidade que exija especificao, na qual seja necessrio 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 so 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, no se esquecendo de utilizar um mtodo de decomposio que nos garanta a possibilidade de, a partir dos subprogramas, reconstituir o todo. evidente que se devem fazer parte integrante do mtodo o reconhecimento e a descrio dos elementos de ligao entre os subprogramas constituintes do todo. Assim, no caso do projeto de uma casa, poderamos dizer que ela se compe de uma sala, trs quartos, dois banheiros, etc. A outra abordagem consiste em decompor o problema no por partes, como um mosaico, mais por pontos de vista diferentes. Nesta abordagem diramos que a casa compe-se de planta de instalao eltrica, uma planta de instalao hidrulica etc.., onde todas as plantas referem-se casa e no apenas uma das partes. Novamente, a integrao entre os componentes do problema original se faz necessria, visto que as plantas componentes da casa no podem ser tratadas isoladamente. Por exemplo, o que aconteceria se, por falta de integrao, a planta de instalao eltrica determinasse a passagem de um cabo eltrica justamente pelo mesmo local onde a planta de instalao hidrulica especificasse a passagem de um cano dgua?O exemplo apresentando apenas tem por objetivo ilustrar algumas das dificuldades enfrentadas na soluo de problemas complexos, e chamamos a ateno do leitor para a utilidade de uma planta para descrever o projeto mencionado, a qual possibilita a resoluo de algumas questes de natureza tcnica, antes do incio da construo, o que se traduz em economia no custo total. Os requisitos do futuro usurio da casa, quanto s suas necessidades, podero ser discutidos fazendo-se uso da planta, o que ajuda a garantir a adequao do projeto s necessidades do usurio. Desta forma, a planta funciona como um modelo reduzido e mais barato da casa e serve ainda como mecanismo (leia-se, linguagem) de comunicao entre tcnicos e entre usurios e tcnicos, pois, em problemas complexos, a soluo ideal s ser alcanada se os tcnicos tiverem forte interao com os usurios 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 informaes, deve-se elaborar um modelo que seja capaz de expressar com a mxima fidelidade possvel o conhecimento que se tem do ambiente onde o sistema ser implantado, de modo a satisfazer a todos os requisitos necessrios. Se, por um lado, o custo de um sistema funo do desempenho de seus componentes, por outro, o valor deste mesmo sistema funo da utilidade que ele tenha para seus usurios. A boa tcnica de anlise dos sistemas de uma empresa preconiza uma boa interao, vale dizer, comunicao - entre os usurios e os tcnicos de informtica.O principal produto da anlise so modelos que daro origem aos sistemas. Entre as utilidades de um modelo, sedestaca as seguintes: Estabelecer uma viso comum. (entre usurios e analista) do ambiente antes da automao; Servir como suporte para negociao e especificao de requisitos e possibilidades futuras para o sistema; Representar, avaliar e refinar conceitos do projeto; Escalonar a informatizao em frases, com produtos bem - definidos e dependncia mnima entre as fases; Tratar a complexidade do problema por nveis de abstrao, comeando pela viso mais abstrata e descendo a vises progressivamente mais detalhadas; Promover indicaes quantitativas do escopo e da complexidade do problema; Prover facilidades para gerao de testes de aceitao;Alm disso, sabe-se que, na especificao dos sistemas de informao, devem ser consideradas diversas perspectivas do problema como nas diversas plantas do exemplo da construo da casa. As modernas abordagens enfatizam a perspectiva dos dados, no ignorando, entretanto, a importncia da perspectiva das funes 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 representao.

2.1 Tcnicas de Levantamento requisitos de software

O incio 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.Anlise e levantamento de requisitos so deextrema importncia serve para um bomDocumento de Requisitos de Software possvel visualizar e interferir em umsistema sem causar problemas aplicaoexistente. Alm disso, o esforo gasto nalocalizao de qualquer tipo de modificaoouimplementao se torna aceitvel (SOMMERVILLE, 2003).

Figura 2.1:disponvel em http://scott.yang.id.au/2003/08/software-development-life-cycle/

Sommerville (2003) prope um processo genrico de levantamento e anlise que contm as seguintes atividades: Compreenso do domnio: Os analistas devem desenvolver sua compreenso do domnio da aplicao; Coleta de requisitos: o processo de interagir com os usurios do sistema para descobrir seus requisitos; Classificao: Essa atividade considera o conjunto no estruturado dos requisitos e os organiza em grupos coerentes; Resoluo de conflitos: Quando mltiplos usurios esto envolvidos, os requisitos apresentaro conflitos. Essa atividade tem por objetivo solucionar esses conflitos; Definio das prioridades: Em qualquer conjunto de requisitos, alguns sero mais importantes do que outros. Esse estgio envolve interao com os usurios para a definio dos requisitos mais importantes; Verificao de requisitos: Os requisitos so verificados para descobrir se esto completos e consistentes e se esto em concordncia com o que os clientes desejam do sistema.O levantamento e anlise de requisitos um processo iterativo, com uma contnua validao de uma atividade para outra, conforme exemplificado pela Figura 2.2:

Figura2.2:Processo de levantamento e anlise 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 produo, o desenvolvimento de sistemas pode envolver diversas fases. Ao encadeamento das fases para a construo 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 prototipao. Adotaremos para nossa explicao o primeiro destes. Simplificadamente,toma-se como base um ciclo de vida de desenvolvimento que ter as seguintes frases, na ordem apresentada a seguir:

ANLISE

PROJETOIMPLEMENTAO Anlise de sistemas ea fase do desenvolvimento em que se determinaro quais os requisitos dos sistemas, o queo sistema deve fazer, em termos essenciais. A fase de anlise tem por objetivo interpretar e definir uma estrutura para um problema ainda no estruturado. Diz respeito eficcia do sistema, ainda sem preocupaes 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 anlise. Diz respeito eficincia do sistema, j com preocupaes de performance. O objetivo desta fase modelar o sistema de modo a implementar a soluo idealizada na fase de anlise, mas de acordo com os recursos tecnolgicos existentes na empresa. Por implementao de Sistemas entenderemos a fase do desenvolvimento em que ser efetuada a construo do sistema de acordo com o modelo de funcionamento especificado na fase de projeto. Faz uso dos recursos tecnolgicos existentes na empresa para atividades como a programao de computadores.O ciclo de vida ilustrado acima um ciclo compulsrio. 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 anlise, e duas outras fases aps a implementao: so elas a simulao e a implantao do sistema. Neste caso, o ciclo de desenvolvimento ficaria assim:

PROJETOANLISEIMPLANTAOSIMULAOIMPLEMENTAOESTUDO

Uma vez implantando o sistema, duas outras fases surgem: operao e manuteno. Ao ciclo de atividades que inclui, alm das fases de desenvolvimento, a operao e a manuteno de um sistema que podemos denominar ciclo de vida do sistema, e faremos a seguinte figura:

ESTUDO ANLISEPROJETOIMPLEMENTAOSIMULAOIMPLANTAO OPERAOMANUTENOPodemos ento dizer que um sistema, uma vez implantado, entra em operaes e, at que seja desativado, poder sofrer manutenes, sejam elas corretivas por acrscimos de novos elementos. Vale ressaltar que o desenvolvimento de sistemas, na prtica, no ocorre de maneira to linear no tempo, como possa parecer pela figura do ciclo da vida. Na prtica, possvel acontecer uma certa superposio de fases, principalmente entre as consecutivas, ainda que tal superposio deva ser reduzida. Por exemplo: pode ser que j se esteja na fase de projeto e seja necessrio, por alguma contingncia, rever uma parte da fase de anlise.

2.2 Metodologias de Desenvolvimento de Sistemas

Para haver sucesso no desenvolvimento de sistemas, torna-se necessria a utilizao de uma metodologia de trabalho.Uma metodologia pode ser entendida como uma dissertao sobre a maneira de se utilizar um conjunto coerente e coordenado de mtodos para atingir um objetivo, de modo que se evite, tanto quanto possvel, a subjetividade na execuo do trabalho.Um mtodo pode ser entendido como um procedimento a ser adotado para se atingir um objetivo. Para tanto, o mtodo se vale de um conjunto de tcnicas.Uma tcnica pode ser entendida como sendo um modo apropriado de se investigar sistematicamente um determinado universo de interesse ou domnio de um problema. Para se expressar, uma tcnica faz uso de uma notao.Uma notao um conjunto de caracteres, smbolos 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 tambm apresentar definio clara de quem faz o qu, quando, como, e at mesmo onde, para todos os que estejam envolvidos diretamente ou no com o desenvolvimento de sistemas. Deve definir tambm qual o papel dos tcnicos de informtica, o dos usurios e o da administrao da empresa no processo de desenvolvimento. Alm disso, deve instituir um conjunto de padres preestabelecidos, de modo a se evitar a subjetividade na abordagem, a fim de garantir a facilidade de integrao de sistemas de desenvolvidos por grupos de pessoas diferentes em pocas distintas. As tcnicas adotadas que devem ser estveis, e no os tcnicos. Deve, assim, evitar um problema muito comum. Em algumas instalaes: onde tcnicos se comportam como verdadeiros donos de determinados sistemas, pois s eles os conhecem bem e s eles so capazes de alter-los sem riscos, o que sem dvida indesejvel para a administrao da empresa. Tudo isto permite uma maior mobilidade na alocao dos recursos-humanos, materiais, financeiros e tempo- envolvidos na atividade e d condies direo 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 tcnicas adotadas. So exemplos de tcnicas: Anlise Estruturada; Anlise Essencial e Projeto Estruturado. A metodologia deve ainda, para cada tcnica adotada, definir quais as ferramentas utilizadas. So exemplos de ferramentas: Diagrama de Fluxo de Dados; Diagrama de Entidade-Relacionamento; Diagrama de Transio de Estados. Cada ferramenta ir produzir um tipo de modelo. So exemplos de modelos: Modelo Funcional Modelo Conceitual de Dados; Modelo de Controle. A metodologia deve estabelecer ainda quais os pontos de controle e padres de qualidade, alm da responsabilidade do pessoal envolvido nos controles e mtricas. Tais tcnicas fazem uso de ferramentas que do origem a modelos que representam as principais perspectivas de um sistema. Entre estas, principalmente nos ambientes de sistemas de informao administrativos, as ferramentas de modelagem como as que so usadas em tcnicas do tipo de Anlise 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 anlise de sistemas por trs tcnicas:Anlise de Sistemas

TCNICASABORDAGENSFERRAMENTAS

ANLISETRADICIONAL*FUNCIONAL

*TEXTOS*FLUXOGRAMAS

ANLISEESTRUTURADA

*FUNCIONAL *DADOS*DIAGRAMA DE FLUXO DE DADOS *DIAGRAMA DE ESTRUTURA DE DADOS*MINIESPECIFICAES*NORMALIZAO *DICIONRIO DE DADOS

ANLISE ESSENCIAL

*FUNCIONAL *DADOS *CONTROLE

*TABELA DE EVENTOS *DIAGRAMA DE FLUXO DE DADOS *DIAGRAMA DE ENTIDADE-RELACIONAMENTO*DIAGRAMA DE TRANSIO DE ESTADOS*DIAGRAMA DE ESTRUTURA DE DADOS*NORMALIZAO *MINIESPECIFICAES*DICIONRIO DE DADOS

O quadro anterior mostra tambm uma espcie de evoluo histrica das tcnicas de anlise. O que estamos denominando por Anlise Tradicional a tcnica que costumava ser usada para a fase de anlise, antes do surgimento da Anlise Estruturada. Basicamente, produzia um documento que, alm 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 funes do sistema.Com o advento da Anlise Estruturada, como se pode notar, passou-se a fazer um uso maior das ferramentas de modelagem, e a abordagem passou a contemplar tambm a perspectiva dos dados, alm da perspectiva das funes.Finalmente, a Anlise Essencial faz amplo uso das ferramentas de modelagem e opta por uma abordagem que contempla tambm a perspectiva dos controles, alm da perspectiva das funes e dos dados. Assim, medida que foram evoluindo as tcnicas de anlise, maior quantidade de ferramentas de modelagem passou a ser utilizada.Embora as ferramentas de modelagem sejam extremamente importantes, por razes diversas, na prtica, algumas empresas ainda relutam na sua adoo. 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 avaliaes, acreditam que, com a adoo destas tcnicas, o desenvolvimento dos sistemas estende-se muito longamente. Segundo esses queixosos, fazendo-se uso de mtodos mais tradicionais, chegar-se ao mesmo objetivo em tempo menor.As vantagens do uso de ferramentas de modelagem so:1)Identificar se o prazo para o desenvolvimento foi realmente mal estimado, sendo que, neste caso, mesmo com mtodos tradicionais, no se teria acertado na previso do tempo;2) Os profissionais que atuam no desenvolvimento do sistema ainda no dominavam a utilizao das ferramentas adotadas pela tcnica. Neste caso, a suposta lentido se deve falta de proficincia dos tcnicos no uso das ferramentas;3) O diagnstico que aponta perda de tempo distoro de parmetro. Isto porque, com a utilizao de ferramentas que permitem um mecanismo rigoroso de verificao, muitas situaes especficas de nveis mais altos-como: as fases conceitual e lgica do sistema - foram corretamente analisadas. Ora, no se pode comparar o tempo que tal anlise demanda com aquele que se consumiria nas anlises realizadas pelos mtodos tradicionais, porquanto ai no teriam contemplado uma srie de situaes que as ferramentas de modelagem apontam. Anlises mais pobres podem at economizar tempo, mas no cobrem a riqueza de situaes que se devem identificar em anlises extremamente mais abrangentes e aderentes ao mundo real.A chave do problema est, principalmente, no item (3). Via de regra, a utilizao de mtodos tradicionais deixa escapar de sua anlise situaes que, pouco tempo aps a implantao, fazem com que o sistema comece a sofrer manuteno. Esta escolha pode ser enquadrada na categoria de solues de curto prazo que acarretam problemas de longo prazo. Uma concluso importante, de tudo quanto temos observado, diz que um sistema menos sujeito a necessidade de manuteno quando mais altos, se fez uso de mtodos mais formais (menos empricos), permitindo identificar, antecipadamente, problemas que s seriam percebidos nas fases finais do desenvolvimento ou aps a implantao do sistema.Outros problemas, tambm citados na utilizao de ferramentas de modelagem, so o volume de documentao produzida e a dificuldade de mant-la atualizada.Quanto ao primeiro problema, podemos afirmar que, para o mesmo volume de documentao, a utilizao de uma ferramenta de modelagem registra uma quantidade de conhecimento (informao) maior do que a registrada por mtodos tradicionais. Isto se deve, entre outros fatores, ao fato de as tcnicas de modelagem fazerem uso de linguagens grficas (bidimensionais), enquanto que as tcnicas tradicionais usam a linguagem textual (que linear). Alm disso, caracterstica da prpria ferramenta de modelagem buscar a no redundncia de informaes, o que, normalmente, no ocorre nos mtodos tradicionais.Quanto dificuldade de se manter a documentao atualizada, cabe dizer que, com qualquer tcnica que se use, isto sempre foi difcil. 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 especificao. Dissemos que a maioria dos sistemas pode ter sua especificao bem compreendida se apresentarmos trs modelos que conceitualmente representam o sistema a partir de trs perspectivas que se completam: modelo funcional, modelo de dados, e modelo controle. Os sistemas podem, ainda ser classificados de acordo com a importncia relativa de cada um dos trs modelos para sua especificao. Desta forma, poderamos classificar os sistemas em centrados nas funes, centrados nos dados e centrados nos controles. verdade que haveria uma srie de sistemas hbridos, os quais no seriam to claramente definidos assim. Para exemplificar, chamaremos de sistema centrado nos dados aqueles cuja precaues(na especificao e implementao) deve ser maior em relao aos dados e seus inter-relacionamento do que em relao s operaes. As aplicaes de robtica so um exemplo de sistemas mis centrado nos controles e processos, enquanto que as aplicaes de consulta generalizada so o extremo de sistemas centrados nos dados. O principal objeto de nosso estudo sero os sistemas de informao administrativos cujas principais perspectivas so a das funes e dos dados, especialmente esta ltima.A tcnica 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 decomposio tanto das funes como dos dados do sistema a partir dos eventos, garantindo, dessa forma, que o modelo de dados e o de funes possam ser construdos simultaneamente, estando assim integrados, por construo.Podemos afirmar, sem receio de errar, que ao adotado a tcnica da Anlise Essencial, como apresentada neste livro, o leitor poder produzir sistemas muito mais efetivos, e em tempo hbil do que se usar qualquer outra tcnica tradicional. Quando se tem o mtodo adequado para resolver um problema, facilmente se encontra a soluo.A tcnica da Anlise Estruturada Moderna. Para compreender os conceitos da Anlise Essencial, necessrio 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 sentenas sobre modelagem de sistemas . Quantas sentenas esto incorretasa )0b)1c)2d )3I. Um modelo enfatiza um conjunto de caractersticas da realidade, que corresponde dimenso do modelo. Alm da dimenso que um modelo enfatiza, modelos possuem nveis de abstrao.II.O nvel de abstrao de um modelo diz respeito ao grau de detalhamento com que as caractersticas do sistema so representadas.III. Em cada nvel h uma nfase seletiva nos detalhes representados.IV.No caso dos sistemas de informao, geralmente, so considerados trs nveis: conceitual, lgico, fsico

4)Pesquise sobre o conceito dos seguintes nveis dos sistemas de informao.

5)No contexto de Metodologias de Desenvolvimento de Sistemas, podemos definir que metodologia pode ser entendida como:a)Uma dissertao sobre a maneira de se utilizar um conjunto coerente e coordenado de mtodos para atingir um objetivo, de modo que se evite, tanto quanto possvel, a subjetividade na execuo do trabalho.b) Um procedimento a ser adotado para se atingir um objetivo. Para tanto, o mtodo se vale de um conjunto de tcnicas.c)Um modo apropriado de se investigar sistematicamente um determinado universo de interesse ou domnio de um problema. Para se expressar, uma tcnica faz uso de uma notao.d)Um conjunto de caracteres, smbolos 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 tcnicas adotadas em uma metodologia para definir 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 anlise de sistemas por as seguintes tcnicas:a)Anlise Tradicionalb)Anlise Estruturadac)Anlise Essencial

9)Quais as principais atividades executadas em um processo de levantamento de requisitos de anlise de Software.

10)Quais as principais tcnicas de especificao?

11) Faa o relacionamento a seguir:a)rvore de decisob)pseudocdigo.c)portugus estruturadod)Tabela de deciso( )Uma forma textual alternativa, e mais popular, da se descrever mini espcies, quase idntica ao portugus estruturado, porm mais prxima das linguagens de programao.( ) uma maneira de expressar, em forma de tabela, qual o conjunto de condies que necessrio ocorrer para que um determinado conjunto de aes deva ser executado.( ) uma representao de uma tabela de deciso sob a forma de uma rvore. Tem a mesma utilidade da tabela de deciso. ( ) Constitui-se em uma verso adaptada de nosso prprio idioma, com nfase em algumas classes gramaticais (no caso, verbos, de preferncia no modo imperativo) acrescida de construes tpicas das estruturas de controle existentes nas linguagens de programao (sequncias, decises e repeties).

12)Como composto uma tabela de deciso em um DFD ?

13)Faa uma comparao entre as Tcnicas de especificaes abaixo ,para descrever como elas so representadas em um DFD.

PORTUQUS ESTRUTURADOPSEUDOCDIGO

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 relaes entre esses componentes. Frequentemente a modelagem de software usa algum tipo de notao grfica e so apoiados pelo uso de ferramentas case. Modelagem de softwares normalmente implica a construo de modelos grficos que simbolizam os artefatos de software utilizados e seus inter-relacionamentos. Uma forma comum de modelagem de programas procedurais (no orientados a objeto) atravs de fluxogramas, enquanto que a modelagem de programas orientados a objeto normalmente usam a linguagem grfica UML(Linguagem de Modelagem Unificada) a qual os fabricantes lderes de modelagem esto dando suporte. Na criao de sistemas com qualidade necessrio a utilizao de uma boa metodologia para a modelagem tanto do software, como de seu banco de dados. Algumas ferramentas j auxiliam na automao da escrita de cdigo e na implementao da estrutura dos bancos de dados. Os banco de dados so modelados atravs 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 criao dos modelos, as mais avanadas permitem a gerao de uma parte do cdigo-fonte do software a partir do modelo e at a gerao 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 informaes a de suas funes. Afinal de contas, todo sistema de informaes armazena e transforma dados de entrada em dados de sada. Estas transformaes so realizadas pelas suas funes.Todo modelo funcional de um sistema pode ser visto como sendo formada por uma representao grfica - uma rede de funes ou processos interligados-, acompanhada de uma descrio de cada funo e das suas interfaces. A representao grfica do modelo funcional costuma ser expresso atravs de um diagrama denominado diagrama de fluxo de dados, abreviadamente, DFD.Um diagrama de fluxo de dados uma forma grfica de mostrar a interdependncia das funes que compem um sistema, apresentando fluxos de dados entre elas. Mostra ainda os arquivos lgicos de dados, que so denominados depsitos de dados, como veremos mais adiante, bem como as entidades externas, denominao 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. Comearemos, na seo seguinte, definindo o que vem a ser uma funo.

3.1.1 O Conceito de Funo

Idealmente, podemos definir uma funo 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 ligaes de entrada e de sada da caixa; Conhecem-se os elementos de entrada da caixa Conhecem-se os elementos de sada 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 sada); No se precisa conhecer como a caixa realiza suas operaes e nem em que ordem.Desta forma, uma funo pode entendida como um componente de um sistema onde somente os dados de entrada e os dados de entrada e os dados de sada so conhecidos. No se conhece explicitamente nada a respeito do processo interno de transformao dos dados de sada. As funes representam as aes que o sistema executa. Ressalte-se que, em qualquer sistema de informaes, nem todas as funes so automatizadas; sempre teremos funes que sero executadas manualmente. Isto significa que devemos representar todas as funes, independentemente de maneira como sero executadas. Convm enfatizar que estamos falando de funes de transformao de dados. No texto deste livro, usaremos s vezes, a palavra processo como sinnimo de funo.

3.2 O Fluxo de Dados

Imagine uma tarefa bem simples, como, por exemplo, o preenchimento manual de um formulrio denominado NOTA DE DBITO. Neste caso, podemos dizer que a funo a ser executada PREENCHER NOTA DE DBITO. Conforme dissemos, para que a funo seja executada, necessria que haja dados de entrada; no caso, um formulrio de nota de dbito em branco. A sada desta funo ser uma nota de dbito preenchida. O diagrama a seguir representa esta situao:

Nota de dbito Preencher Nota de dbitoem branconota de dbitopreenchida

Na figura anterior, a funo est sendo representada por uma forma oval, com uma seta de entrada e uma de sada. As setas esto representando o que chamaremos de fluxo de dados de entrada e de sada. Esta denominao tem por objetivo dar a idia de dados em movimento. Fluxos de dados so condutos que levam informao de um ponto de sistema para outro; mostram como os dados fluem atravs do sistema, o caminho percorrido pelos dados no sistema para outro; mostram como os dados fluem atravs do sistema, o caminho percorrido pelos dados no sistema. e no o suporte material onde um fluxo de dados representa um conjunto de dados e no o suporte material onde identificamos o conjunto de dados. Trata-se de fluxo de dados e no de fluxo de material. Portanto, no devemos confundir a nota de dbito com o formulrio onde os dados so preenchidos. Quando estamos escrevendo no fluxo de dados Nota de dbito estamos nos referindo ao contedo do formulrio (os dados formulrio) e no ao formulrio em si.

Se acrescentarmos ao nosso pequeno sistema a funo DIGITAR NOTA DE DBITO, teremos o seguinte diagrama:

Digitar nota de dbitoNota dedbitopreenchida

Nota de dbitodigitadaPreenchernota de dbitoNota de dbitoem branco

3.3Os Depsitos de Dados

No DFD anterior, temos duas funes em sequncia, onde a sada da primeira funo a entrada da segunda. Desta forma a entrada da funo DIGITAR NOTA DE DBITO a sada da funo PREENCHER NOTA DE DBITO. Assim sendo, para que a funo DIGITAR NOTA DE DBITO seja executada antes dela.Podemos ento perguntar: para que a 2 funo seja executada, necessrio que a 1 funo seja executada imediatamente antes? fcil responder que no, pois, na verdade, o que precisamos para executar DIGITAR NOTA DE DBITO do formulrio NOTA DE DBITO preenchido.Evidentemente, podemos preencher um formulrio em um determinado momento, guard-lo e, num tempo posterior, digit-lo. Queremos representar dados que vo ficar armazenados como num arquivo.Ao conjunto de dados armazenados denominaremos depsito de dados. Constituem a memria 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 representao adiante.

Nota dedbitodigitadaNota dedbitopreenchidaNota dedbitopreenchida

Digitar nota de dbitoPreenchernota de dbitoNota de dbitoem branco

Uma das maneiras usadas para identificar num DFD os pontos de reteno de dados, locais onde os dados esto armazenados, ou seja, os depsitos de dados, atravs de duas barras paralelas, em posio vertical ou horizontal. Portanto, uma determinada funo (PREENCHER NOTA DE DBITO) produz como sada um determinado conjunto de dados. A seguir, uma outra funo (DIGITAR NOTA DE DBITO) obtm (l) como dados de entrada o contedo do depsito de dados nota de dbito preenchida e produz como sada um outro conjunto de dados (nota de dbito digitada), que conduzido pelo fluxo de dados nota de dbito digitada. Vale sublinhar que estamos nos referindo a depsitos de dados a no a arquivos fsicos. Estamos nos referindo s estruturas de dados lgicas e no aos meios fsicos (fichrios, arquivos magnticos etc.) que possam vir a ser usados na fase de implementao para suport-las.

3.4 As Entidades Externas

At aqui, j vimos como representar uma funo, suas entradas e suas sadas, bem como dados que devam ser armazenados para posterior utilizao. 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 vo os fluxos de dados de sada 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 influncia sobre o comportamento do sistema.Se observarmos o pequeno sistema que descrevemos, podemos perguntar:*De onde vem o fluxo de dados notas de dbito?*Para onde vai o fluxo de dados nota de dbito digitada?De modo a responder s perguntas acima, precisamos representar os elementos externos, que enviam e recebem informaes do sistema. A esses elementos denominaremos terminais ouentidades externas. So 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 rgo ou uma atividade de uma empresa ou entidade governamental, um outro sistema etc.

A ilustrao de tais elementos apresentada a seguir:

DEPARTAMENTO DE COBRANA ARTAMENTODE COBRANAPreencher DigitarNota de dbitonota de Nota de dbito nota de dbito nota de nota de dbito

SISTEMA DE COBRANAem branco dbito preenchida preenchida dbito digitada

Na figura anterior, usamos uma das maneiras de representar as entidades externas. No caso, quadrilteros, normalmente, retngulos ou quadrados.A seguir, apresentamos um DFD um pouco maior onde se podem ver todos os seus elementos componentes:

CLIENTELista de compras CADASTRAR LISTA DEDIRETORIA COMPRASLISTA DE COMPRAS Lista de comprasListadeitem de comprademanda

EMITIR LISTA DEProdutoPRODUTOSProduto CADASTRAR DEMANDA PRODUTOS

RAZOSOCIALRazo

LISTA DEPRODUTOSsocialLista de

FORNECEDORESFornecedores CADASTRARPedido de FORNECEDORFORNECEDORESCadastramentoFornecedores

Atividade:a)Quais os elementos componentes de um DFD?-funes ou processos;-fluxos de dados;-depsitos de dados;-entidades externas.

b) Um DFD apresenta componentes externos (terminais ou entidades externas) e componentes internos (funes, fluxos de dados e depsitos de dados).

c) Um DFD apresenta componentes ativos (as funes) e componentes estticos (depsitos de dados).

d) Um DFD pode ser visto como um modelo que apresenta as funes de um sistema

e) As informaes de um sistema podem ser apresentar em termos estticos (depsitos de dados) ou em movimento (fluxo de dados).

f) Um fluxo de dados liga:-uma entidade externa a uma funo-uma funo a uma entidade externa;-uma funo a um depsito de dados;-um depsito de dados a uma funo.-uma funo a outra funo.

ATIVIDADE

1)Em analise de Essencial, como podemos definir o modelo funcional de dados?2)No modelo funcional, que tipo de representao utilizada para representar suas funes?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 notao utilizada para representar seus componentes ?8)Nos Diagramas de Fluxo de Dados (DFD) , o que so os Depsitos de Dados?9) Que regras deveremos adotar para a construo de DFD?10)De acordo com o DFD da figura abaixo:

Identifique:a)Quais so os processos deste DFD? E quais so as entidades externais? b)Quais so os depsitos de dados deste DFD? E quais so os fluxos de dados? c)Existem fluxos de dados invlidos neste DFD? Quais so eles? Por que eles so invlidos? 11) O que significa a seguinte afirmao: A continuidade do fluxo de informao deve ser mantida entre os diferentes nveis 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 denominaes dadas aos componentes, avaliar seu objetivo

15) DFD diagrama de fluxo de dados: Analise o seguinte DFD e responda s questes colocadas

a) com base no DFD representado, indique se este possui alguma incorreo derepresentao.b) refaa o DFD, com as correes que achar necessrias.c) para o arquivo de dados clientes e a entidade FORNECEDOR descreva a respectiva entrada de dados no dicionrio de dados.4 DIAGRAMA DE CONTEXTOSe 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 possvel representao de um sistema aquela em que ele apresenta como uma nica grande funo, cercada pelas entidades externas que com ele interagem. Por intermdio de fluxos de dados.Para ilustrar esta idia, voltemos ao sistema que se suponha a produzir o fluxo de dados nota de dbito digitada. Se observarmos a figura a seguir, podemos com, por exemplo, uma linha dupla estabelecer a fronteira do sistema:

DEPARTAMENTO DE COBRANAPreencher

Nota de dbitodigitadaNota de dbitopreenchida

Digitar nota de dbitoNota de dbitopreenchidaPreenchernota de dbitoNota de dbitoem branco

SISTEMA DE COBRANA

Como consequncia, pode-se expressar tal sistema como o diagrama:

DEPARTAMENTO Obter SISTEMA DE Nota de dbito nota de Nota de dbito DE COBRANA em branco dbito digitada COBRANA

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 CADASTRARLISTA DECOMPRAS

DIRETORIA LISTA DE COMPRAS Lista de ComprasLista De item de comprademanda

EmitirLista de produto PRODUTOS produto CADASTRAR Demandas PRODUTOS

Razo Social lista de produtos

FORNECEDOR fornecedores CADASTRAR Pedido de FORNECEDORFORNECEDORES cadastramento de fornecedores

E chegaremos ao seguinte diagrama de contexto:

CLIENTELista de Compras

DIRETORIALista de fornecedor Sistema de Acompanhamento da Demanda de ProdutosLista deprodutos

Pedido de Cadastramento de FORNECEDOR

Ao analisar as duas situaes mostradas, podemos concluir que:a) O sistema Obter Nota de Dbito Digita pode ser decomposto em duas funes: 1)Preencher Nota de Dbito;2)Digitar Nota de Dbito.b) O Sistema de Acompanhamento de demanda de Produtos pode ser decomposto em quatro funes:1)Cadastrar Produtos;2)Cadastrar Fornecedores;3)Cadastrar Lista de Compras;4)Emitir Lista de Demanda.

Como consequncia, podemos concluir que:-Um DFD uma representao 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 funes que se interligam. Note que as entidades externas no diagrama expandido (DFD que apresenta as funes do sistema) so as mesmas do Diagrama de Contexto, no qual, entretanto, so mostrados apenas os fluxos de dados que representam a interface do sistema com as entidades externas.-para cada funo do sistema, podemos aplicar esse mesmo prncipio e decomp-la em funes mais simples, ou seja, subfunes.Todo sistema pode ser representado como um grande processo, interagindo como o ambiente em que est inserindo.Isto significa que a primeira viso de um sistema o diagrama de contexto.Como desenhar um diagrama de contexto?Passo n1)Desenhar um nico processo ou funo para representar o sistema inteiro.

CIA.END- VIDA

Passo n2)Desenhar todas as entidades externas que se comunicam com o sistema.

DEPTO.PLANE-JAMENTOCLIENTE CIA. END- VIDADA

FORNE- DEPTO- CEDOR FINAN-CEIRO

Passo n3)Para cada entidade externa, desenhar o fluxo de dados que mostra sua comunicao com o sistema

PAGAMENTO CLIENTE DEPTO. PLANE-CLIENTE PEDIDO JAMENTO CLIENTE CIA.. RELATRIO FATURA-CLIENTE END- VIDADA FINANCEIRO

ENCOMENDA COMISSO DOS VENDEDORES

FATURA DO FORNECEDOR DEPTO.FORNE FINAN-CEDOR PAGAMENTO CEIRO FORNECEDOR

H quem discuta se, em um Diagrama de Contexto, J poderiam aparecer depsitos de dados ou no. Particularmente, preferimos no apresent-los neste nvel. 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 decomposio sucessiva e hierrquica, que toma a forma de uma rede onde cada n (funo ou processo) pai pode ser decomposto em outra rede de funes filhas com os respectivos fluxos de dados e depsitos de dados do nvel imediatamente inferior, e assim sucessivamente, at que no possa mais ser decomposta. A funo que no possa mais ser decomposta denominada funo primitiva, ou primitiva funcional. Trata-se de uma funo bsica ou atmica - que no mais possa ser subdividida. Em resumo, todo DFD pode ser decomposto em DFDs de nvel inferior, recursivamente, at alcanarem-se as primitivas funcionais. Trata-se de uma fatorao hierrquica. A ilustrao a seguir nos mostra esta situao.

E1E3 FD1 FD7 SISTEMANvel FD2FD8Contexto E2E4

SISTEMA E1E3 FD1 P2 FD7 FD5 Nvel 0 FD6 P4 E2 FD2 FD3 P1 FD4 P3 FD8 E4

P3

P2 FD6 P3.1 P3.3Nvel 1 P1 FD4 P3.2 P3.4 FD8 E4

Apresentamos, inicialmente, um Diagrama de Contexto do sistema, onde:

-as entidades externas esto representadas por E1, E2, E3 e E4;-os fluxos de dados so representados como FD1, FD2, FD7, e FD8.No passo seguinte, exibido o primeiro nvel de particionamento do sistema, onde:-os processos (funes) do sistema so representados por P1, P2, P3, e P4.-alm dos fluxos de dados j apresentados, aparecem ainda FD3, FD4, FD5 e FD6Em seguida, ilustrada a decomposio do processo P3,onde:-aparecem processos com as denominaes P3.1, P3.2, P3.4.- apresentado ainda um depsito de dados entre os processos P3.1 e P3.3.-aparecem entidades externas com as denominaes P1, P2 e E4.Algumas observaes se fazem necessrias:a) Um sistema de tamanho razovel, normalmente, no deve ser modelado em nico DFD, pois o modelo poderia ficar ininteligvel.b)Para resolver este problema, so construdos vrios DFDs representando o sistema em sucessivos nveis de detalhe, chamados nveis de abstrao. A esta estratgia costuma-se chamar nivelamento. Na figura anterior foram apresentados trs nveis de abstrao. Cada DFD representa o detalhamento (exploso) do DFD de um nvel imediatamente superior. Uma maneira de identificar os nveis de abstrao numer-los em ordem sequencial, tal como nvel zero, nvel 1, nvel 2, nvel3 etc.A abordagem em que efetuamos a decomposio do sistema, partindo do diagrama de contexto (nvel mais geral) e descendo passo a passo a nveis mais baixo (mais detalhados), denominada abordagem top-down. Foi a abordagem preconizada pela tcnica de anlise denominada Anlise Estruturada, muito popular desde o final da dcada de 1970 at meados da dcada de 1980. Uma outra abordagem possvel, oposta top down, denominada bottom-up parte do nvel mais detalhado para o nvel mais geral. Outras abordagens tambm conhecidas so as denominadas outside-in, inside-out, ou ainda midle-out.Numa decomposio do tipo top-down, possvel que, em um determinado nvel algumas funes j sejam primitivas funcionais, enquanto outras ainda no o so. Estas ainda daro origem a DFDs mais detalhados (de nvel mais baixo). Uma imagem que pode ser adotada a de se considerarem as primitivas funcionais como sendo tomos que ao se agregarem vo formar as molculas de uma substncia. conveniente que, em cada nvel de abstrao, as funes estejam em grau de detalhamento prximo, ou seja, no convm que em um dos nveis do DFD uma das funes ainda precise ser decomposta em sub-funes de muitos nveis de abstrao inferiores at chegar primitiva funcional, enquanto outras funes do mesmo DFD j so primitivas. Cada DFD deve apresentar um nvel de detalhe equilibrado. Os processos que tratam de rotinas de erros e de excees devem ser expressos nos nveis mais baixos.Para alguns autores, cada nvel de DFD deve ter de 5 a 9 funes. Segundo os defensores desta idia, esta uma boa maneira de se tratar a complexidade do sistema, visto que um DFD com inmeras funes tornar-se-ia de difcil leitura.c)Sempre que ocorre particionamento, deve ser garantida a consistncia entre as entradas e sadas de cada dois nveis de particionamento sucessivos. Em outras palavras, h uma espcie de conservao de energia ou conservao dos dados, no sistema. A esta necessidade costuma-se chamar balanceamento.Ao particionar um processo, qualquer fluxo de dados, depsito de dados ou entidade externa que aparea a ele ligado no nvel de cima tem de aparecer no DFD do nvel imediatamente inferior.Do ponto de vista de quem observa o sistema a partir do exterior, no pode haver fluxos de dados de entrada ou de sada no nvel inferior que no existam no de cima. Tanto no Diagrama de Contexto como no nvel imediatamente inferior, temos os mesmos fluxos de dados servindo de interface entre o sistema e o seu exterior, 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 sada, 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 so considerados entidades externas. Esta conduta nos ajuda a garantir a consistncia entre os diversos nveis de particionamento. Note que estamos chamando P1e P2 de entidades externas, apenas em relao exploso do processo P3; mas no para o sistema como um todo.e)A maneira usada para expressar a correspondncia entre os nveis pais e nveis filhos da especificao estruturada foi a designao numrica mostrando a que diagrama pai corresponde um diagrama filho. Em consequncia, P3.1, P3.2 e P3.3 so processo filhos do processo pai P3. Se, por exemplo, o processo P3.2 ainda no 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, trs problemas afloram:no lera)Qual o critrio de particionamento de uma funo que deve ser usado?Por ora, podemos responder que, luz dos conhecimentos atuais sobre este assunto, o melhor critrio o de particionar uma funo de tal forma que nos DFD resultante as sub-funes componentes tenham a mnima quantidade de interfaces possvel. Voltaremos a este ponto mais tarde, quando, esperamos, este assunto ficar mais claro.b)O modelo das funes compe-se apenas de uma representao diagramtica? No. A especificao do modelo das funes (especificao funcional) inicia-se com a decomposio do diagrama de contexto em sucessivos DFDs, cada vez mais detalhados, at que se chegue s funes primitivas. Apenas os desenhos no so suficientes para que se possa compreender o modelo das funes. Dessa maneira, falta ainda descrever o contedo dos fluxos de dados e dos depsitos de dados. Isto se faz atravs de uma linguagem de descrio apropriada para esta necessidade, a qual veremos no momento oportuno. Por outro lado, ao de chegar s funes primitivas, passa-se a especificar de forma descritiva, fazendo uso das tcnicas estruturadas de especificao.Em uma especificao funcional, apenas as descries das funes primitivas so apresentadas e so chamadas miniespecificaes (miniespecs). Mais adiante veremos como se faz isto.c) At quando se deve continuar particionando as funes?Poderamos dizer que cada n pai deva ser particionado em uma rede de ns filhos at que o nvel desejado de detalhe seja alcanado, e ai estaramos diante de funes primitivas. Entretanto, qual deve ser o nvel de detalhe desejado? Aqui reside um problema, pois no h uma medida precisa sobre se uma funo ainda deve ser decomposta ou no.Como regra puramente prtica, pode-se dizer que uma funo primitiva aquela que:

-pode ser descrita em apenas uma pgina, quer esta pgina represente a descrio de um pequeno procedimento manual ou um mdulo de um programa de computador, ou;-sua descrio, em pseudocdigo, no ultrapassa 50 a 100 linhas.Para armazenar as descries mencionadas, necessrio um procedimento especfico para este objetivo. Isto apresentado no captulo seguinte.

6 O DICIONRIO DE DADOSConforme dissemos, o modelo funcional composto de uma representao grfica e uma descrio dos componentes do modelo-entidades externas, funes, fluxos de dados e depsitos 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 informaes sobre os componentes dos sistemas. Para tanto, conforme proposto pela literatura, usado um sistema, que vai guardar informaes (metadados) sobre os sistemas de nosso interesse, denominado dicionrio de dados. Um dicionrio de dados um repositrio de informaes sobre os componentes dos sistemas. Para descrever os componentes de sistema, devemos adotar uma linguagem apropriada. Vrias formas podem ser usadas para, por exemplo, apresentar os dados de um fluxo de dados. Utilizaremos os seguintes smbolos:

SMBOLOSIGNIFICADO

= equivalente a

{ }Ou

*(min-max)Repeties

[ ]Opcional

@Chave

% %Comentrio

6.1 Descries dos Fluxos de Dados

Seja mostrar a composio do fluxo de dados denominados FATURA-CLIENTE de o DFD a seguir:

PAGAMENTO DO CLIENTE DEPTO.CLIENTE PLANEJA- PEDIDO-CLIENTE MENTO

RELATRIO FINANCEIRO CIA. FATURA-CLIENTE END-VIDADA

ENCOMENDA COMISSO DOS VENDEDORES FATURA DO FORNECEDOR DEPTO FINAN-FORNE- PAGAMENTO AO FORNECEDOR CEIROCEDOR

fatura-cliente = NUM-FATURAcod-clienteender-clienteproduto *(1-10) VALOR-TOTAL-FATURA

produto = COD-PRODUTO PREO-UNITRIO QTDE-PEDIDA VALOR-TOTAL-PRODUTO

ender-cliente = RUA NMERO COMPLEMENTO NOME-BAIRRO[CEP]SIGLA-UF% sigla da unidade da Federao% TELEFONE% telefone para contato, inclui DDD%

cod-cliente = {CPF-CLIENTE%CPF, se pessoa fsica ou %CGC(cadastro geral contribuinte)-CLIENTE}%CGC, se pessoa jurdica %

Como se pode notar, foram usadas letras maisculas para identificar dados elementares (que no podem ser decompostos), ao passo que foram usadas letras minsculas para identificar os casos em que temos uma estrutura de dados (caso em que temos, na verdade, um agregado de outros dados, como, por exemplo, ender-cliente). Vale ressaltar que este tipo de procedimento recursivo, ou seja, uma estrutura de dados pode ser decomposta,ou ainda, uma combinao dos dois.

A leitura da descrio nos d conta de que: Fatura-cliente e ender-cliente so estruturas de dados, enquanto que VALOR-TOTAL-FATURA e RUA so dados elementares; Produto uma estrutura que pode ocorrer no mnimo uma vez at o mximo de dez vezes em cada fatura-cliente; No caso de CEP, vemos que foi definido como sendo um dado elementar opcional na estrutura de ender-cliente; Ao lado de SIGLA-UF foi colocada uma explicao para ilustrar o uso do smbolo que expressa um comentrio;para exemplificar a utilizao do smbolo que serve para expressar o caso em que apenas uma das alternativas vlida, foi apresentada a definio de cod-cliente que dependendo do tipo de cliente, pode ser identificado pelo CPFou pelo CGC.Pode-se imaginar um dicionrio de dados como um sistema de apoio especificao do sistema em desenvolvimento, uma vez que todas as definies dos componentes do sistema ali estaro armazenadas.De maneira rudimentar, pode-se imaginar o dicionrio de dados como sendo um fichrio que contm uma ficha para cada componente do sistema, como na figura a seguir.

DICIONRIO DE DADOS

Fluxo de dados : Nome-cliente

Depsito de dados : Clientes

Dado elementar: CidadeEstrutura de dados: Endereo Por ora, estamos colocando no dicionrio de dados apenas os componentes do modelo de funes. Todavia, para ser completo, ele deveria, ainda, conter os componentes de dados e do modelo de controle, que veremos em prximos captulos, alm de informaes adicionais que se fizessem necessrias. Como dissemos, o dicionrio de dados deve ser um sistema que descreve o sistema de nosso interesse. Hoje em dia, existem no mercado diversos sistemas automatizados de dicionrio de dados, com inmeros recursos disponveis. O leitor no precisa se preocupar em desenvolver um. Basta apenas conhecer o conceito e usar o que esteja disponvel em sua instalao. Alm disso, com a evoluo dos softwaresdo tipo CASE (Computer Aided Software Engeneering), que servem de apoio ao desenvolvimento de sistemas, j se pode ter um auxlio bastante grande na tarefa de documentao.

6.2 Descrio dos Depsitos de Dados

Seja o trecho de DFD mostrado na figura a seguir:

Gerncia Operacional

Cadastrar Cadastrar Loja livro

Loja Livro

Incrementar Estoque

Sistema de Compras

Estoque Loja

Para descrever os depsitos de dados, usando-se a linguagem de descrio de dados, por ns definida, teremos:loja = NUM-LOJAender-loja

livro =@COD-LIVROTTULO-LIVRONOME-AUTOR-PRINCIPAL NUM-EDIOPREO-UNITRIO

estoque-loja = @NUM-LOJA@COD-LIVROQTDE-EM-ESTOQUENVEL-DE-REPOSIO

ender-loja = RUANMEROCOMPLEMENTONOME-BAIRRO[CEP]SIGLA-UF% da unidade de Federao %TELEFONE % telefone para contato, inclui DDD%

No se esquecer de que, como um depsito de dados representa um conjunto de dados como se fora um arquivo(note que no estamos nos referindo a arquivos fsicos do sistema, pois ainda no os protejamos nesta fase do desenvolvimento), podemos imaginar os depsitos de dados como sendo compostos de registros com as estruturas anteriormente definidas. Cabe ressaltar que para se ter acesso a cada registro individualizado de cada depsito de dados foi usado o conceito de chave de acesso, sendo usado o smbolo @para assinalar os elementos ou estrutura de dados que tenham esse papel. Resulta da que a chave para acesso ao depsito de dados livro COD-LIVRO; a chave do depsito loja NUM-LOJA, enquanto que a chave para o depsito estoque-loja composta pela concatenao de NUM-LOJA e COD-LIVRO, pois somente assim poderemos saber qual a quantidade de um determinado livro em uma determinada loja.Uma forma diferente e mais sinttica de apresentar a composio de um depsito de dados ou de um fluxo de dados atravs de um conjunto de campos (dados elementares ou estruturas de dados) separados por vrgulas, onde os campos (dados elementares ou estruturas de dados) separados por vrgulas, onde os campos que formam a chave dos depsitos esto sublinhados.

loja = {NUM-LOJA, RUA, NMERO, COMPLEMENTO, NOME-BAIRRO, CEP, SIGLA-UF, TELEFONE}

livro = {COD-LIVRO, TTULO-LIVRO, NOME-AUTOR-PRINCIPAL, NUM-EDIO, PREO-UNITRIO}

estoque-loja = {NUM-LOJA, COD-LIVRO, QTDE-EM-ESTOQUE, NIVEL-DE-REPOSIO}

7 A ESPECIFICAO DOS PROCESSOS

Ao chegar ao nvel das funes primitivas, encontramo-nos diante do problema de como descrever tais funes, com clareza e preciso. Alm disso, temos de considerar que a descrio da funo primitiva dever ser lida pelos analistas de sistemas e pelos futuros usurios do sistema em desenvolvimento, os quais, no necessariamente, tm formao que permita entender, por exemplo, o jargo tcnico da informtica. Portanto, no podemos usar a linguagemcomum, pois notrio que tal opo d margem a toda subjetividade de quem descreve, com todas as possibilidades de ser produzido um texto redundante, ambguo, confuso, inconsistente e incompleto.Para solucionar este problema, e lembrando que a descrio de uma primitiva funcional no pode ser bem compreendida sem se ter idia do contexto em que se acha inserida, devemos estabelecer algum balizamento sobre os seguintes aspectos: O que deve e o que no deve ser descrito; Que tipo de tcnica deve-se usar na descrio.Em relao ao primeiro aspecto, temos a considerar:

NaEspecificao dos Processos no necessrio repetir o que jfoi definido nos DFDs e no dicionrio de dados, como o caso das descries dos fluxos de dados e dos depsitos de dados, redundncia de deve ser evitada, sempre que possvel; Toda especificao deprocessos deve definir a forma pela qual os fluxos de dados de entrada so transformados em fluxos de dados de sada, independentemente do fato de a funo ser executada manualmente ou por qualquer outra forma de implementao;Em relao ao segundo aspecto, as principais tcnicas de especificao so: Portugus estruturado Pseudocdigo Tabela de deciso rvore de deciso

7.1 Portugus Estruturado

Seja o trecho de DFD com a primitiva funcional a seguir, que representa uma funo de um sistema escolar que executada ao final do perodo de aulas:

DISCIPLINAS

ALUNOS APROVADO

EMITIR AVISO EM RECUPERAO DE SITUAO DO ALUNO

REPROVADO AVALIAES-DE-ALUNOS

Sejam os seguintes os depsitos de dados:

ALUNOS = @MATR-ALUNONOME-ALUNOender-aluno

ender-aluno = RUA NMERO COMPLEMENTONOME-BAIRRO[CEP] SIGLA-UF% sigla da unidade da Federao% TELEFONE% telefone para contato, inclui DDD%

AVALIAES-DE-ALUNOS = @MATR-ALUNO @COD-DISCIPLINAMDIA-FINAL

DISCIPLINAS =@COD-DISCIPLINANOME-DISCIPLINACONTEDO-PROGRAMTICO

Precisamos descrever qual o procedimento a ser adotado para emitir o aviso sobre a situao do aluno. A tcnica que usaremos denomina-se portugus estruturado e constitui-se em uma verso adaptada de nosso prprio idioma, com nfase em algumas classes gramaticais (no caso, verbos, de preferncia no modo imperativo) em detrimento de outras (normalmente adjetivos e advrbios, pois estas classes do margem a confuses que devem ser evitadas em nome da clareza e preciso) acrescida de construes tpicas das estruturas de controle existentes nas linguagens de programao (sequncias, decises e repeties). Busca estabelecer comunicao de alto nvel com o usurio, atravs de termos que lhe so familiares, e Assim, teremos:

EMITIR AVISO DE SITUAO DO ALUNO

PARA CADA aluno no arquivo de alunos: (condies pr e ps-condies)

1. Coloque a matrcula, o nome e o endereo do aluno no formulrio de aviso.2. PARA CADA cod-disciplina, cursada pelo aluno, existente no arquivo de avaliaes:2.1 Obtenha, a partir do arquivo de disciplinas, o nome da disciplina.2.2 Obtenha, a partir do arquivo de avaliaes, a mdia final do aluno na disciplina.2.3 Coloqueno formulrio de aviso o cdigo, o nome e a mdia final da disciplina cursada pelo aluno.3. Calcule o total de disciplinas em que o aluno obteve mdia final menor do que 5.3.1 (CASO 1) nenhuma disciplina com mdia final menor do que 5.3.1.1Coloque no formulrio com a expresso APROVADO.

3.2 (CASO2) mais de trs disciplinas com mdias finais menores do que 53.2.1Coloque no formulrio a expresso REPROVADO.3.3 (CASO3) menos de quatro disciplinas com mdias finais menores do que 53.3.1 Coloque no formulrio a expresso EM RECUPERAO.

Como se pode observar, usamos aqui construes anlogas a estruturas tpicas das linguagens de programao, como repetio (PARA CADA....), sequncia (coloque, calcule etc...), e seleo (CASO1; CASO2;...). Esta ltima parte da especificao tambm poderia ser expressa por estruturas ainda mais comuns nas linguagens de programao, quando se quer exprimir a noo de seleo. E, ento, poderamos ter algo parecido com o if-then-else, como o seguinte trecho:

3.Calcule o total de disciplinas em que o aluno obteve mdia final menor do que 5.

SE em nenhuma disciplina a mdia final foi menor do que 5,Coloque no formulrio de aviso a expresso APROVADO.

SE NO, SE em mais de trs disciplinas houve mdia final menor do que 5,Col